Area
CLI
What are you trying to accomplish?
Avoid scheduling and locking a history migration that is provably a no-op, without racing another writer or skipping the backup/manifest accounting expected by the migration workflow.
What prevents this today?
A pre-lock probe can observe “nothing to migrate” and then race a concurrent apply/restore operation before returning. An early return for a missing database can also bypass the backup-manifest path, producing a false impression that the full migration contract completed.
The current locked path is conservative and safe, but it can do unnecessary work. The reviewed optimization did not preserve the same authority boundary.
What should OpenCodex do?
Only return a no-op after proof under the same coordinator/lock or an equivalent fenced snapshot. The proof should include the relevant database identity/generation and desired-operation state, preserve required backup/manifest accounting, and fall back to the normal locked migration if any observed generation changes.
Example usage or interface
admit migration request
-> acquire the existing coordinator/lock (or a fenced read lease)
-> read database identity + migration need + backup accounting state
-> unchanged and empty: record a verified no-op and return
-> changed/unknown: execute the normal migration path
A concurrent apply operation must invalidate the no-op proof rather than being skipped.
Alternatives or workarounds
- Keep the current conservative worker path: safe, with extra work.
- Probe before coordination: faster in the common case, but subject to TOCTOU.
- Return immediately when the database is absent: can omit backup/manifest semantics.
Additional context
The worker receives an already-derived operation in src/codex/history-job.ts; skip is the only current pre-spawn no-op. Provider or worker code may separately observe a missing database or zero candidate rows, but that observation is not fenced against a concurrent apply/restore and does not prove the backup manifest needs no reconciliation. A worker-level optimization therefore has to make the database, operation generation, and manifest proof one coordinated decision.
Checks
Area
CLI
What are you trying to accomplish?
Avoid scheduling and locking a history migration that is provably a no-op, without racing another writer or skipping the backup/manifest accounting expected by the migration workflow.
What prevents this today?
A pre-lock probe can observe “nothing to migrate” and then race a concurrent apply/restore operation before returning. An early return for a missing database can also bypass the backup-manifest path, producing a false impression that the full migration contract completed.
The current locked path is conservative and safe, but it can do unnecessary work. The reviewed optimization did not preserve the same authority boundary.
What should OpenCodex do?
Only return a no-op after proof under the same coordinator/lock or an equivalent fenced snapshot. The proof should include the relevant database identity/generation and desired-operation state, preserve required backup/manifest accounting, and fall back to the normal locked migration if any observed generation changes.
Example usage or interface
A concurrent apply operation must invalidate the no-op proof rather than being skipped.
Alternatives or workarounds
Additional context
The worker receives an already-derived operation in
src/codex/history-job.ts;skipis the only current pre-spawn no-op. Provider or worker code may separately observe a missing database or zero candidate rows, but that observation is not fenced against a concurrent apply/restore and does not prove the backup manifest needs no reconciliation. A worker-level optimization therefore has to make the database, operation generation, and manifest proof one coordinated decision.Checks