Repository navigation
F1/G4: persist planning failure reasons and atomic snapshot binding #34
Description
Lane E uses the existing Store interface without changing shared persistence. Integration handoff for F1/G4: Store requests currently persist identity/revision/state/reply only. E keeps failure/timeout/cancellation reasons in returned outcomes and checks the snapshot immediately before publication in its single coordinator; this is not cross-process atomic snapshot CAS.
Before exposing production planning: bind the request to the captured snapshot/attempt in persistence, atomically compare that binding when publishing and applying, persist terminal reasons, and supply restart recovery/admission through the runner owner. Keep ready historical results visible but stale after context changes. Preserve Store as the sole writer.
Acceptance: independent-process snapshot change between E validation and Store publication/Apply is rejected without overwriting newer state; restart retains actionable timeout/failure reasons and cannot revive an active/cancelled request. Live adapter integration waits for D5. This belongs to the existing F1/G4 planning persistence/API contract, not a second E storage layer. Related: #29, #6.
Activity
mchwang commentedon Sep 24, 2026
Blocking E3 review finding, reproduced on 2026-09-24 (PR #35 head a1a72b2; integrated fixture head 886ccf5). Interleaving: E reads pending; independent Store connection completes the same request; immediately before E publication CAS, asserted durable state ready and exact validated reply; E completeSuggestions refuses; unconditional E cleanup calls current Store.cancelSuggestions, which cancels both pending and ready. Observed outcome failed, durable state cancelled, reply retained but Apply unavailable. This is a concrete failing-before reproduction, not a summary-only concern.
Required F-owned prerequisite: an atomic pending-attempt cleanup operation (identity + opaque request/attempt ID + expected pending state), preserving ready/consumed results. E must use it for automatic failure/stale cleanup and cancellation settlement, with controlled independent-connection regressions covering completion before publication and before cleanup. A separate read then existing cancelSuggestions is not sufficient. Existing explicit user cancellation semantics may remain separate.
The lane plan prohibits E from modifying shared Store/schema interfaces. PR #35 is now a blocked draft; E4 #37 remains a dependent draft. Resume E3 after the Store owner publishes/lands this interface, add the passing-after regression, then finish review. Keep the prior durable reasons/snapshot binding integration work in this issue as well.
mchwang commentedon Sep 24, 2026
I’m taking #34 on branch
codex/planning-request-lifecyclefrom current main. Scope:runner/store.ts, Store regressions, and the persistent-store lifecycle contract. Done when controlled two-connection tests cover snapshot changes, completion/cleanup races, stale Apply rejection, and restart recovery of terminal reasons; focused Store tests, full tests, typecheck, and browser tests pass on the exact pushed head.mchwang commentedon Sep 24, 2026
Implemented in #43 at
884c7ef. Exact-head validation is green (346 unit/integration tests, typecheck, 43 browser tests), GitHub CI is green, and Copilot review round 1 returned no findings. The PR is clean and mergeable; E3 #35 remains blocked until this prerequisite lands.