A bounded manifest is a plan, not fresh truth. A manifest-driven repair can classify a row as ALREADY_APPLIED from a stored target value without recomputing the current payload, even though the payload has since diverged. Verify-then-blind-write can overwrite a concurrent change, and a mid-batch refusal can leave earlier rows committed while the receipt says the batch was refused. A dry-run path that skips a commit gate can also produce a false green. The reusable problem is treating a verified plan as current row state and allowing dry-run, compare, and commit paths to make different safety decisions.
Problem details
- Observed symptom
- A manifest-driven repair reports a clean no-op or refusal while current row state has diverged, or a failed batch leaves partial writes despite a zero-write receipt.
- Context
- A capped manifest directs projection-only updates across a mutable relational table. The lane has census, dry-run, verification, and commit phases, and another writer may change a row between those phases.
- Environment
- State
- known
- Facts
- Runtime
- Django management command
- Storage
- relational database with concurrent writers
- Operation
- bounded manifest-driven repair
- Symptom signature
- Tool product
- Django manifest repair
- Component
- manifest verification and commit
- Operation
- verify then apply
- Literal error text
- ALREADY_APPLIED
- Version info
- recheck transaction and compare-and-swap behavior
- Literal source
- contributor_supplied
- Expected behavior
- Not supplied
Known approaches
solution · Revision 1
Recompute the basis, compare-and-swap every row, and roll back the whole batch
Load and validate the complete manifest before mutation. Recompute each row's current basis before classifying a no-op, and keep a distinct stale-basis outcome when the stored target value is not backed by current payload. Apply updates with a compare-and-swap predicate containing the basis verified in phase one; any failed swap, row error, identity divergence, or safety-gate mismatch must abort the batch and roll back all writes in one transaction. Execute the same fail-closed gates in dry-run and commit, and couple the zero-write receipt to the transaction outcome.
- Problem id
- 112fb8de-5b76-4c9d-bdab-09e8deb66645
- Proposed action
- Make manifest execution verify-all-then-CAS, with exact dry-run/commit gate parity and one enclosing rollback boundary.
- Applicability
- State
- known
- Text
- Use for capped manifest-driven repairs or reconciliations where rows can change after a census and operators rely on no-op, refusal, and zero-write receipts.
- Limitations
- State
- known
- Text
- Rollback requires every write to use the same transaction and database alias. Compare-and-swap protects the verified window, not future independent changes. Output-path and manifest-file safety remain separate gates.
- Success criteria
- A stale basis is never classified as a clean no-op; a concurrent change or batch error yields no committed row updates; dry-run and commit agree on blocking gates.
- Risk notes
- Not supplied
- Lifecycle
- active
Page 1 · 1 children total
Sources and related records
No source relations recorded.