morluto/rea

Fork 0

mirror of https://github.com/morluto/rea.git synced 2026-11-05 06:45:22 +00:00

[PR #6388] [CLOSED] fix(sqlite): attribute result-column limit to columns instead of data… #7329

New issue

Closed

opened 2026-11-01 21:47:05 +00:00 by bsakaguchi · 0 comments

bsakaguchi commented

2026-11-01 21:47:05 +00:00

Owner

📋 Pull Request Information

Original PR: https://github.com/morluto/rea/pull/6388
Author: @ahmed-husssain
Created: 10/22/2026
Status: ❌ Closed

Base: main ← Head: fix/sqlite-column-limit-attribution

📝 Commits (1)

6fd3b23 fix(sqlite): attribute result-column limit to columns instead of database format

📊 Changes

3 files changed (+120 additions, -0 deletions)

View changed files

📝 src/sqlite/SqliteDatabaseInspection.ts (+6 -0)
📝 tests/acceptance/sqliteDatabaseCli.test.ts (+60 -0)
📝 tests/boundary/sqlite/sqliteDatabaseInspection.test.ts (+54 -0)

📄 Description

Summary

Fixes #6292.
When inspecting an SQLite table with more selected columns than SQLite's result-column limit (SQLITE_MAX_COLUMN), the engine returns SQLITE_ERROR with message "too many columns in result set". The worker previously fell back to format classification on path, reporting healthy databases as invalid.

Attribute result-column limits to column-selection in readRows so the error identifies columns as the failing argument and preserves the SQLite reason.

Problem and expected behavior

Smallest trigger: inspect_sqlite_database with >2,000 columns (e.g. columns: Array(2001).fill("email")).
Violated invariant: Rejections must attribute failures to the argument requiring correction (columns), preserve the engine's reason, and avoid classifying healthy database files as invalid/malformed.
Expected behavior: Rejection targets path: ["columns"] with reason: "invalid_format" and message "too many columns in result set". Malformed files continue reporting format error on path.

Change and scope

In src/sqlite/SqliteDatabaseInspection.ts: catch "too many columns in result set" in readRows and throw SqliteInspectionFailure("column-selection", message).
Reuses the existing "column-selection" protocol and error mapping in SqliteDatabaseWorkerExecution.ts (rejectedArgument["column-selection"] = "columns").
Contribution scope: not applicable (ordinary bug fix within existing SQLite provider boundary).

Contract and boundary impact

Semantic owner and earliest changed stage: SqliteDatabaseInspection.ts (query preparation / execution).
Contribution scope fit and linked maintainer decision: not applicable.
CLI and MCP/tool-catalog contract: Unchanged schema. Identifies columns rather than path as the invalid argument when result-column limits are exceeded.
Provider, bridge, target-format, or platform compatibility: Standard SQLite result-column limit behavior.
Evidence, artifact, provenance, or reconstruction contract: Database files remain read-only and unmutated.
Read existing files or captured data.
Launch or attach to a process.
Inject instrumentation or run scripts/code.
Change process memory, registers, files, or configuration.
Contact network services.
Recover protected code or work around protections.
Documentation or usability only; no target interaction.
Not sure yet; investigation or maintainer guidance needed.

Evidence and regression coverage

Tests added or updated:
- tests/boundary/sqlite/sqliteDatabaseInspection.test.ts: asserts inspectSqliteDatabaseSnapshot throws SqliteInspectionFailure with reason: "column-selection" when result-column limits are exceeded.
- tests/acceptance/sqliteDatabaseCli.test.ts: verifies MCP tool response reports path: ["columns"] on >2000 columns while genuine malformed control files report path: ["path"].
Base reproduction: Base revision threw raw ERR_SQLITE_ERROR and returned Selected SQLite database is invalid (too many columns in result set) targeting path: ["path"].

User-visible CLI/MCP output:

{
  "error": {
    "code": "invalid_request",
    "category": "invalid_input",
    "retryable": false,
    "details": {
      "issues": [
        {
          "path": ["columns"],
          "reason": "invalid_format",
          "message": "too many columns in result set"
        }
      ]
    }
  }
}

Observed, derived, and inferred claims remain distinguishable.
Artifact identity, source provenance, and failed attempts remain preserved.
Unsupported, incomplete, unavailable, or uncertain outcomes remain visible.

Validation performed

node node_modules/vitest/vitest.mjs run tests/boundary/sqlite/sqliteDatabaseInspection.test.ts — PASS (25 passed, 1 skipped)
node node_modules/vitest/vitest.mjs run tests/acceptance/sqliteDatabaseCli.test.ts -t "attributes SQLite result-column limits" — PASS (1 passed, 14 skipped)
npx oxfmt --check src/sqlite/SqliteDatabaseInspection.ts tests/acceptance/sqliteDatabaseCli.test.ts tests/boundary/sqlite/sqliteDatabaseInspection.test.ts — PASS (all matched files formatted)
npm run check:fast — PASS (Turbo typecheck and oxlint clean)

Compatibility, safety, and release

Breaking changes or migration steps: None.
Real Hopper/Ghidra, browser, or OS coverage: SQLite inspection provider on Node.js runtime.
Package or release metadata impact: None.
Security, privacy, process, or containment review: Read-only query execution in ephemeral snapshot worker; no mutation or credential exposure.

Author readiness

Human owner: @ahmed-husssain

I reviewed the final diff and relevant existing code, understand the change and its edge cases, and take responsibility for the complete PR, including AI-assisted work.
I checked the evidence above, confirmed it supports the current change, and recorded meaningful validation gaps.
I declare this PR ready for initial maintainer review.

Before merge

This PR addresses a concrete problem or an agreed enhancement.
Material scope and authority questions are resolved, and any required maintainer scope decision covers the final diff.
The PR has one focused outcome and the title follows type(scope): outcome.
Related issue is linked, or the reason for not linking one is stated above.
Tests cover changed observable behavior and meaningful failure paths.
Owning docs, contracts, and generated metadata are updated where needed.
User-visible CLI/MCP changes include representative output.
I checked the final diff for secrets, unrelated cleanup, and unsupported claims.


---

<sub>🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.</sub>

## 📋 Pull Request Information **Original PR:** https://github.com/morluto/rea/pull/6388 **Author:** [@ahmed-husssain](https://github.com/ahmed-husssain) **Created:** 10/22/2026 **Status:** ❌ Closed **Base:** `main` ← **Head:** `fix/sqlite-column-limit-attribution` --- ### 📝 Commits (1) - [`6fd3b23`](https://github.com/morluto/rea/commit/6fd3b23a483a652c36d2405b210be3e23a589fc9) fix(sqlite): attribute result-column limit to columns instead of database format ### 📊 Changes **3 files changed** (+120 additions, -0 deletions) <details> <summary>View changed files</summary> 📝 `src/sqlite/SqliteDatabaseInspection.ts` (+6 -0) 📝 `tests/acceptance/sqliteDatabaseCli.test.ts` (+60 -0) 📝 `tests/boundary/sqlite/sqliteDatabaseInspection.test.ts` (+54 -0) </details> ### 📄 Description ## Summary Fixes #6292. When inspecting an SQLite table with more selected columns than SQLite's result-column limit (`SQLITE_MAX_COLUMN`), the engine returns `SQLITE_ERROR` with message `"too many columns in result set"`. The worker previously fell back to format classification on `path`, reporting healthy databases as invalid. Attribute result-column limits to `column-selection` in `readRows` so the error identifies `columns` as the failing argument and preserves the SQLite reason. ## Problem and expected behavior - Smallest trigger: `inspect_sqlite_database` with >2,000 columns (e.g. `columns: Array(2001).fill("email")`). - Violated invariant: Rejections must attribute failures to the argument requiring correction (`columns`), preserve the engine's reason, and avoid classifying healthy database files as invalid/malformed. - Expected behavior: Rejection targets `path: ["columns"]` with `reason: "invalid_format"` and message `"too many columns in result set"`. Malformed files continue reporting format error on `path`. ## Change and scope - In `src/sqlite/SqliteDatabaseInspection.ts`: catch `"too many columns in result set"` in `readRows` and throw `SqliteInspectionFailure("column-selection", message)`. - Reuses the existing `"column-selection"` protocol and error mapping in `SqliteDatabaseWorkerExecution.ts` (`rejectedArgument["column-selection"] = "columns"`). - Contribution scope: not applicable (ordinary bug fix within existing SQLite provider boundary). ## Contract and boundary impact - Semantic owner and earliest changed stage: `SqliteDatabaseInspection.ts` (query preparation / execution). - Contribution scope fit and linked maintainer decision: not applicable. - CLI and MCP/tool-catalog contract: Unchanged schema. Identifies `columns` rather than `path` as the invalid argument when result-column limits are exceeded. - Provider, bridge, target-format, or platform compatibility: Standard SQLite result-column limit behavior. - Evidence, artifact, provenance, or reconstruction contract: Database files remain read-only and unmutated. - [x] Read existing files or captured data. - [ ] Launch or attach to a process. - [ ] Inject instrumentation or run scripts/code. - [ ] Change process memory, registers, files, or configuration. - [ ] Contact network services. - [ ] Recover protected code or work around protections. - [ ] Documentation or usability only; no target interaction. - [ ] Not sure yet; investigation or maintainer guidance needed. ## Evidence and regression coverage - Tests added or updated: - `tests/boundary/sqlite/sqliteDatabaseInspection.test.ts`: asserts `inspectSqliteDatabaseSnapshot` throws `SqliteInspectionFailure` with `reason: "column-selection"` when result-column limits are exceeded. - `tests/acceptance/sqliteDatabaseCli.test.ts`: verifies MCP tool response reports `path: ["columns"]` on >2000 columns while genuine malformed control files report `path: ["path"]`. - Base reproduction: Base revision threw raw `ERR_SQLITE_ERROR` and returned `Selected SQLite database is invalid (too many columns in result set)` targeting `path: ["path"]`. - User-visible CLI/MCP output: ```json { "error": { "code": "invalid_request", "category": "invalid_input", "retryable": false, "details": { "issues": [ { "path": ["columns"], "reason": "invalid_format", "message": "too many columns in result set" } ] } } } ``` - [x] Observed, derived, and inferred claims remain distinguishable. - [x] Artifact identity, source provenance, and failed attempts remain preserved. - [x] Unsupported, incomplete, unavailable, or uncertain outcomes remain visible. ## Validation performed - `node node_modules/vitest/vitest.mjs run tests/boundary/sqlite/sqliteDatabaseInspection.test.ts` — PASS (25 passed, 1 skipped) - `node node_modules/vitest/vitest.mjs run tests/acceptance/sqliteDatabaseCli.test.ts -t "attributes SQLite result-column limits"` — PASS (1 passed, 14 skipped) - `npx oxfmt --check src/sqlite/SqliteDatabaseInspection.ts tests/acceptance/sqliteDatabaseCli.test.ts tests/boundary/sqlite/sqliteDatabaseInspection.test.ts` — PASS (all matched files formatted) - `npm run check:fast` — PASS (Turbo typecheck and oxlint clean) ## Compatibility, safety, and release - Breaking changes or migration steps: None. - Real Hopper/Ghidra, browser, or OS coverage: SQLite inspection provider on Node.js runtime. - Package or release metadata impact: None. - Security, privacy, process, or containment review: Read-only query execution in ephemeral snapshot worker; no mutation or credential exposure. ## Author readiness Human owner: @ahmed-husssain - [x] I reviewed the final diff and relevant existing code, understand the change and its edge cases, and take responsibility for the complete PR, including AI-assisted work. - [x] I checked the evidence above, confirmed it supports the current change, and recorded meaningful validation gaps. - [x] I declare this PR ready for initial maintainer review. ## Before merge - [ ] This PR addresses a concrete problem or an agreed enhancement. - [ ] Material scope and authority questions are resolved, and any required maintainer scope decision covers the final diff. - [ ] The PR has one focused outcome and the title follows `type(scope): outcome`. - [ ] Related issue is linked, or the reason for not linking one is stated above. - [ ] Tests cover changed observable behavior and meaningful failure paths. - [ ] Owning docs, contracts, and generated metadata are updated where needed. - [ ] User-visible CLI/MCP changes include representative output. - [ ] I checked the final diff for secrets, unrelated cleanup, and unsupported claims. ``` --- <sub>🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.</sub>

bsakaguchi

2026-11-01 21:47:05 +00:00

closed this issue
added the
pull-request
label

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

morluto/rea#7329

No description provided.

Rows
Columns