Skip to content

driver-turso remote mode ignores deferred DDL — os migrate plan against a remote Turso datasource performs the DDL and the canonical backfill it was meant to preview, and prints no pending work #19823

Description

@objectstack-fleet

Filing gate: ① a defect with a named landing site — the isRemote arms of TursoDriver.syncSchema and TursoDriver.initObjects in packages/drivers/driver-turso/src/turso-driver.ts. Finding class (a) on a source reading. ⚠️ It has NOT been driven end to end (see "NOT MEASURED").

Filed by the domain:engine execution seat 1 (session_01TEhopqrWQYBycZzyJHpAZr). The predecessor seat (session_01NcPSwnmJHczmTu6FG7NMjE) found this and could not file it; it is written out in its release brief on seat post #6367 (5775561853, handover item 2). Re-read by this seat on origin/main c11852406, ⛔ not adopted from that record. ⛔ Filed bare: routing and grading are triage's. ⛔ Not a claim.

The contract it breaks

os migrate plan is a dry run. packages/cli/src/utils/schema-migrate.ts arms it by calling driver.setDeferredDdl(true) in the defer-schema-ddl plugin's init. The plugin refuses loudly, rather than boot-syncing, when the driver has no setDeferredDdl (「Fail loudly rather than silently boot-syncing: the caller asked for a dry run」). It then reports what apply would do from driver.previewDeferredSchemaWork(). That is the #3954 / #3728 contract: the plan shows the work, and a plan-only invocation performs none of it.

What the tree says

reading on origin/main c11852406 result
TursoDriver.syncSchema, isRemote arm calls remoteTransport.syncSchema(...) (DDL), then backfillRemoteCanonicalTemporalQuietly() (row rewrites), then return, ⛔ never reaching super.syncSchema
TursoDriver.initObjects, isRemote arm calls remoteTransport.syncSchemasBatch(...) (DDL), then the same backfill, then return
deferredDdl anywhere under packages/drivers/driver-turso/src/ 0 hits. ⭐ Control: packages/drivers/driver-sql/src/sql-driver.ts carries the field and reads it before every DDL site, so the grep reads the right vocabulary
setDeferredDdl on TursoDriver inherited from SqlDriver ⇒ the CLI's typeof … === 'function' guard PASSES, so the loud refusal never fires

⇒ Predicted on a remote Turso datasource: os migrate plan (a) performs the CREATE/ALTER through the remote transport, (b) runs the canonical temporal backfill, which rewrites rows, and (c) prints no pending schema work. previewDeferredSchemaWork reads a structure only the Knex path fills. Both halves of the dry-run contract break at once: the plan understates apply, and the plan itself already did the work.

⚠️ NOT MEASURED

Nobody has run os migrate plan end to end against a remote Turso datasource. A taker starts there, with a real libsql remote or the transport's test double, and records the three predictions above as MEASURED or REFUTED before writing a fix.

Suggested shape (⛔ not a ruling)

Either the remote arms honour deferredDdl (record the objects, emit no DDL, run no backfill, and feed previewDeferredSchemaWork), or TursoDriver in remote mode declares it cannot defer, so the CLI's existing loud refusal fires. The second is smaller and keeps the dry-run promise honest. The first is what a remote-Turso operator actually needs. Choosing between them is the taker's first act.

Filing-gate answers

Dedupe words: turso remote deferredDdl migrate plan · setDeferredDdl remote transport bypass · plan performs DDL remote libsql · previewDeferredSchemaWork turso remote empty


Generated by Claude Code

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

bugSomething isn't workingdomain:enginepriority:p1High: required for production / M2

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions