[GH-ISSUE #2613] fix(sqlite): identify columns in rejected column-selection metadata #929

New issue

Closed

opened 2026-10-15 18:29:40 +00:00 by bsakaguchi · 0 comments

bsakaguchi commented

2026-10-15 18:29:40 +00:00

Owner

Originally created by @coygeek on GitHub (Oct 13, 2026).
Original GitHub issue: https://github.com/morluto/rea/issues/2613

Summary

Requesting an unknown column from an existing SQLite table produces an input error whose structured correction path identifies table. The message correctly identifies the missing column, but clients using the correction path receive the wrong argument to repair.

Steps to reproduce

On the stated source baseline, create a quiescent database with CREATE TABLE records(id INTEGER, label TEXT); INSERT INTO records VALUES(1,'alpha');.
Call SqliteDatabaseProvider.inspect({path: databasePath, table:"records", columns:["nope"], row_limit:5}) and project the returned error with projectAnalysisError.
Examine details.issues[0].path and the message. Repeat with table:"absent" and no column selection, then with table:"records", columns:["id"].

A focused source test executed these requests with the supported injected launcher. The launcher reads the request, calls the production inspectSqliteDatabaseSnapshot against the captured snapshot, writes its inspection or SqliteInspectionFailure reason/message in the worker reply format, then returns a zero-exit child with successful cleanup. This tests production inspection and reply projection without requiring a compiled worker executable.

Expected behavior

The unknown-column error should identify columns, optionally including the rejected element index, as the argument requiring correction. A missing table should still identify table. A valid column selection should return the requested rows.

Actual behavior

The unknown-column case returned this correction issue:

{"path":["table"],"reason":"invalid_format","message":"Selected column does not exist with that exact name in table records: nope"}

The missing-table control also identified table, while selecting id from records succeeded. The executed test did not exercise an automated client's repair loop.

Evidence

Expected source: src/domain/analysisErrorCore.ts:69-72 defines input issues as correction metadata for a rejected caller argument; docs/sqlite-databases.md:57-63 assigns exact column-name selection to columns.
Failure source: src/sqlite/SqliteDatabaseInspection.ts:394-398 classifies a missing column as selection; src/sqlite/SqliteDatabaseWorkerExecution.ts:86 maps every selection failure to the table argument. The focused test observed the projected issue above and checked missing-table and valid-column controls.
Evidence provenance: observed
Local verification: reproduced
Reproduction completeness: complete

Restoration check

For the same unknown-column request, the correction path must identify columns and the message must still identify the rejected name. Keep the unknown-table control attributed to table, and keep the valid id selection successful. A correction that merely moves every selection failure to columns would fail the table control.

Runtime or environment

Source baseline 8b181716ac; Node.js v26.10.0, npm 11.19.1, Vitest 5.0.3. Focused source test with an injected worker launcher.

Triage assessment

Impact level: P2
Assessment status: supported
Impact basis: The structured correction result names the wrong input field for a supported selection failure. Clients relying on that metadata can repair the wrong argument. Inspection correctly refuses the unknown column, so successful database results are not corrupted.
Workaround status: available
Workaround basis: The observed message names both the missing column and its existing table, allowing a caller to correct the columns argument manually.

Originally created by @coygeek on GitHub (Oct 13, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/2613 ## Summary Requesting an unknown column from an existing SQLite table produces an input error whose structured correction path identifies `table`. The message correctly identifies the missing column, but clients using the correction path receive the wrong argument to repair. ## Steps to reproduce 1. On the stated source baseline, create a quiescent database with `CREATE TABLE records(id INTEGER, label TEXT); INSERT INTO records VALUES(1,'alpha');`. 2. Call `SqliteDatabaseProvider.inspect({path: databasePath, table:"records", columns:["nope"], row_limit:5})` and project the returned error with `projectAnalysisError`. 3. Examine `details.issues[0].path` and the message. Repeat with `table:"absent"` and no column selection, then with `table:"records", columns:["id"]`. A focused source test executed these requests with the supported injected launcher. The launcher reads the request, calls the production `inspectSqliteDatabaseSnapshot` against the captured snapshot, writes its inspection or `SqliteInspectionFailure` reason/message in the worker reply format, then returns a zero-exit child with successful cleanup. This tests production inspection and reply projection without requiring a compiled worker executable. ## Expected behavior The unknown-column error should identify `columns`, optionally including the rejected element index, as the argument requiring correction. A missing table should still identify `table`. A valid column selection should return the requested rows. ## Actual behavior The unknown-column case returned this correction issue: ```json {"path":["table"],"reason":"invalid_format","message":"Selected column does not exist with that exact name in table records: nope"} ``` The missing-table control also identified `table`, while selecting `id` from `records` succeeded. The executed test did not exercise an automated client's repair loop. ## Evidence - Expected source: `src/domain/analysisErrorCore.ts:69-72` defines input issues as correction metadata for a rejected caller argument; `docs/sqlite-databases.md:57-63` assigns exact column-name selection to `columns`. - Failure source: `src/sqlite/SqliteDatabaseInspection.ts:394-398` classifies a missing column as `selection`; `src/sqlite/SqliteDatabaseWorkerExecution.ts:86` maps every selection failure to the table argument. The focused test observed the projected issue above and checked missing-table and valid-column controls. - Evidence provenance: observed - Local verification: reproduced - Reproduction completeness: complete ## Restoration check For the same unknown-column request, the correction path must identify `columns` and the message must still identify the rejected name. Keep the unknown-table control attributed to `table`, and keep the valid `id` selection successful. A correction that merely moves every selection failure to `columns` would fail the table control. ## Runtime or environment Source baseline 8b181716aca2cb467be499cba226abfb5ae19141; Node.js v26.10.0, npm 11.19.1, Vitest 5.0.3. Focused source test with an injected worker launcher. ## Triage assessment - Impact level: P2 - Assessment status: supported - Impact basis: The structured correction result names the wrong input field for a supported selection failure. Clients relying on that metadata can repair the wrong argument. Inspection correctly refuses the unknown column, so successful database results are not corrupted. - Workaround status: available - Workaround basis: The observed message names both the missing column and its existing table, allowing a caller to correct the columns argument manually.

bsakaguchi

2026-10-15 18:29:40 +00:00