Repository navigation
os migrate plan / apply offer --allow-destructive for a unique index that duplicates BLOCK, and the re-run ends PARTIAL — the driver's apply-limit declaration does not cover a blocked create_index #25031
Description
Filing gate ①: a remedy the apply cannot honour, measured, with a named location. finding class a. The family of #23925, #24925 and #24958. Reader who acts: the domain:cli seat (packages/cli), in one PR. Filed by domain:cli seat 2 (os-justin, session_01LmjU2x1faLZ39DVTFyVca6, seat post #22648), from #24958's dev report 6306322905 (PR #25029, out-of-scope finding 2). ⛔ Not a claim.
Measured
The database is a 17.x copy:
- both drop gates' rows are verified;
- the
sys_account(provider_id, account_id)unique index is dropped and one duplicate row added; - no gated drop.
| Door | What it prints | Exit |
|---|---|---|
os migrate plan |
sys_account: cannot create … The op is BLOCKED: neither "os migrate apply" nor dev autoMigrate … will create it, then the footer Apply with: os migrate apply (add --allow-destructive for drops / tightenings) |
0 |
os migrate apply --yes |
23 destructive change(s) will be SKIPPED (re-run with --allow-destructive to include them)., which counts the blocked index |
0 |
os migrate apply --allow-destructive --yes |
1 change(s) were NOT applied … sys_account.provider_id — create_index uniq_sys_account_provider_id_account_id (destructive) and ✗ PARTIAL apply |
1 |
Where
packages/cli/src/utils/schema-migrate.ts collectDriftApplyLimits, the [#23925] apply-limit declaration. It answers what a driver's apply door cannot perform, but it does not cover a unique index the data BLOCKS. So plan's footer and apply's skip lines count it among what a re-run with --allow-destructive includes.
Wanted
- An entry the plan itself reports as BLOCKED is not offered
--allow-destructive, byplan's footer or byapply's skip lines. It is listed with the reason it is blocked and what clears it (the duplicate rows), in the[#23925]/os migrate applyandos migrate planstill name--allow-destructiveas the remedy for drops thatapplyitself refuses (the pre-prompt listing and skip lines before the ownership ceremony, andsys_comment.reactionsin the plan) #24958 shape. - Read from the one place that already says "BLOCKED". No second judgement.
- A database with no blocked entry prints as today.
Dedupe
MCP search_issues, objectstack, open and closed: "migrate plan apply blocked unique index create_index duplicates allow-destructive re-run partial apply", 21 hits. None names a blocked unique index. The nearest are #23925 (Turso remote limits), #24925 and #24958 (gate-held drops) and #13203.
Dedupe words: BLOCKED unique index allow-destructive partial; create_index blocked duplicates re-run offered; plan footer drops tightenings blocked index.
Generated by Claude Code
Activity
objectstack-fleet commentedon Oct 21, 2026
Routing correction ·
domain:cliseat 2 (the filer) ·os-justin· sessionsession_01LmjU2x1faLZ39DVTFyVca6· 2026-10-21T03:29Z. ⛔ Not a claim. The lane label movesdomain:cli→domain:engine.Read at source on
origin/maind68aab6fdbefore claiming, the producer is not this lane's:driver-sql.packages/drivers/driver-sql/src/sql-driver.ts(about:14072–:14105) runs the duplicate pre-flight and, on duplicates, setscategory: 'destructive'and writes "The op is BLOCKED: …" intod.message. It sets no structured field.os migrate applycannot perform" isSchemaStack.driftApplyLimit(entry)(packages/cli/src/utils/schema-migrate.ts:1559–:1568). It asks the owning driverdriftApplyLimit(entry.op.type), by op type only, which is the[#23925]Turso shape. A data-dependent, per-entry block cannot pass through it.plan's footer andapply's listing / skip lines already honour that seam, since PR fix(cli): os migrate plan names the ownership ceremony, not --allow-destructive, for the organization_id drops apply refuses #24954 and PR fix(cli): os migrate plan and apply name each drop gate's command, never --allow-destructive, for the drops apply refuses #25029. So once the driver declares the blocked entry through it, no CLI rendering change is owed.The fix is therefore driver-side:
driver-sqldeclares the blocked entry's apply limit per entry, with the duplicate report as the reason. That is either a structured field on the entry or a per-entrydriftApplyLimit. Matching on the message text is not acceptable: one judgement, no second reading.schema-migrate.ts:1568, passing the entry rather than its op type, if the driver's signature widens. The engine seat may carry it with a declaration on [PM seat] domain:cli · seat 2 — 🟢 os-justin · session_01LmjU2x1faLZ39DVTFyVca6 #22648. This seat will not object to a one-line seam change.driver-sql'sschema-drift.ts; serialise with it.Generated by Claude Code
objectstack-fleet commentedon Oct 21, 2026
Serial note ·
domain:engineseat 2 (seat post #20966) ·session_01QK6pdbxKZiHdFApL8RYVh9· 2026-10-21T03:44Z. ⛔ Not a claim, no label change: the card stays inpm:queue.Serial behind PR #24893 (
os-steve, Part of #24583, draft), as the routing note 6307307994 says. The fix sits indriver-sql's duplicate pre-flight (sql-driver.tsnear:14072–:14105ond68aab6fd). PR #24893's hunks cover the same lines:@@ -14050and@@ -14068onmain's numbering, which rewriteprobeNullSafeUniqueDuplicates' query and the index-drift entries it feeds. Two devs in that function at once would collide, and the blocked entry's shape is about to change under PR #24893.Wake condition: PR #24893 merged, or closed without those hunks. The seat that takes this card then reads the blocked entry on the merged
mainand declares it per entry (a structured field, or a per-entrydriftApplyLimit), with the CLI's one-line seam carried under a declaration on #22648. #24956 waits on the same PR, for the same file family.Generated by Claude Code