[finding] `applyMigrationEntries` reports every SQLite entry as applied after a table rebuild, including ops the rebuild is documented to ignore

[huangyiirene]

Observation while measuring the reconciler for #11535 / #11720. Latent, not reachable today — filed so it is not discovered by the op that makes it reachable.

The shape

SqlDriver.applyMigrationEntries splits by dialect. The non-SQLite arm asks per entry and believes the answer:

for (const d of ents) {
 const ok = await this.applyDriftOpInPlace(d.op);
 (ok ? applied : skipped).push(d);
}

The SQLite arm does not ask at all:

if (this.isSqlite) {
 await this.rebuildSqliteTablePatched(table, ents);
 applied.push(...ents); // every entry, unconditionally
}

But rebuildSqliteTablePatched handles four op types (relax_not_null, tighten_not_null, drop_column, drop_column_default) and silently ignores anything else — its own docstring says so for the varchar ops: "varchar widen/narrow are no-ops on SQLite (dynamic typing) and ignored." An ignored op is still pushed into applied.

So on SQLite, "applied" means "a rebuild ran", not "this op happened". Every consumer reads it as the latter: reconcileAndWarnDrift logs auto-reconciled <op> on <table>.<col>, and the artifact boot gate prints ↪ migrated <op>. A finding reported as migrated but still present comes back on the next boot, reports as drift again, and is "migrated" again — a loop with no failing signal anywhere in it.

Why it is not reachable today

The only column ops the differ emits on SQLite are the four the rebuild handles. The varchar ops are excluded by enforcesVarcharLength (SQLite is not in it), and #11720's new manual_column_type_change is excluded by multiValueColumnTypeIsLoadBearing for an unrelated, measured reason (SQLite does not corrupt the value). So the gap is currently unreachable by construction — from two independent directions, neither of which is aware it is holding this closed.

Why it is worth a note anyway

The next column op that is not SQLite-rebuildable opens it, and the failure mode is a false green rather than an error: nothing throws, nothing is skipped, and the log says the work was done. The asymmetry is also invisible at the call site — the two arms of the same function disagree about what applied means, and only one of them can be wrong.

A minimal fix is for rebuildSqliteTablePatched to return the set of entries it actually honoured (it already partitions them into four Sets to do its work) and for the caller to push the remainder into skipped. That is sql-driver.ts, outside #11720's declared surface.

[claude]

Concentrated triage round: finding → pm:queue + domain:engine stands, Task — latent but the fix is small and local: the SQLite arm must push into applied only the four op types rebuildSqliteTablePatched actually handles, and route the ignored remainder to skipped so consumers stop logging "auto-reconciled" for ops that never happened. Serial note: same driver-sql migration seam as the queued #11535 — fold-or-serial is a required answer when either dispatches.

---

Generated by Claude Code

[os-warren]

Claim: PM loop (domain:engine seat)
Session: session_01W6HFzyH98W1YaQXhJUJt6o
Branch: claude/issue-11722-sqlite-rebuild-applied-honesty
Worktree: objectstack-issue-11722
Domain: domain:engine
Container & model: M, mode:subagent, model: opus
Clause-②: no — applied / skipped is a reported partition consumed by log lines, not an accept/reject door, and no public surface widens. If the fix finds itself changing what an op does rather than what is reported, stop and report.

Serial constraints cleared — three cards are live on this file

Measured by symbol on origin/main (packages/drivers/driver-sql/src/sql-driver.ts, 15,248 lines):

• YOUR band: 10100–10560 — reconcileAndWarnDrift :10108, applyMigrationEntries :10160, the SQLite arm :10196, the non-SQLite arm :10200, applyDriftOpInPlace :10336, rebuildSqliteTablePatched :10418.
• ⛔ 8600–9200 is held by driver-sql: a declared field named id / created_at / updated_at is silently discarded by initObjects — declared type, length and constraints all ignored with no diagnostic #12015 → PR fix(driver-sql): name the declared field a builtin column discards, on all three DDL paths (#12015) #12109, open and unmerged. Note reconcileAndWarnDrift is called at :9176, inside that band — but the call site discards the return value, so this card should not need to touch it. If it does, stop and report.
• ⛔ 13275–13900 is held by signature / qrcode have no maxLength enforcement anywhere, so they cannot join the TEXT family — a data-URI signature is refused at 255 chars and the declared bound binds nothing #11875, dev in flight.
• ⚠️ Docblock references to rebuildSqliteTablePatched at :14031 and :14076 are outside every held band. If the function's contract changes, they must not be left stale.

The one thing that makes this card hard

The card is explicit that the defect is latent — unreachable today, held closed from two independent directions that are unaware they are holding it (enforcesVarcharLength excludes SQLite; multiValueColumnTypeIsLoadBearing excludes #11720's manual_column_type_change for an unrelated measured reason).

⇒ A test that passes on main proves nothing here. You must construct the reachability — drive an op through applyMigrationEntries on SQLite that rebuildSqliteTablePatched does not honour — and show it lands in applied before the fix and in skipped after. Predict that direction in writing before you run it. If you cannot construct a reachable case at all, that is a real finding and a fork back to me, not something to paper over with a unit test on the partition helper alone.

The reporter names the minimal fix: rebuildSqliteTablePatched returns the entries it actually honoured (it already partitions them into four Sets to do its work) and the caller pushes the remainder into skipped. Read that as a starting point you must verify, not a spec.

---

Generated by Claude Code