Hare/yoi
1
1
Fork 0
Code Actions Packages Releases Activity

fix: retain Restore recovery intent and retire stale caller conflicts (T-701)

Browse Source
This commit is contained in:
Hare
2026-10-06 18:15:31 +09:00
parent fdce12a47b
commit 6f9621ca2e
8 changed files with 629 additions and 14 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/architecture/worker-restore-observations.md
+2 -2
View File
@@ -43,8 +43,8 @@ Preparation completion is attached to that same pending operation, not a replace
| Workspace alias, scoped and Worker-control HTTP | Mandatory public request; common target/auth reception and the same Runtime admission |
| Embedded / remote Runtime providers and management HTTP | Typed Runtime request and coordination transport, including original observation and lifecycle operation owner |
| `WorkerRestore` Tool | Observed token in Tool arguments and durable Tool-call-derived request identity |
| Existing TUI Restore/resume path | Selected row's observation token and retained request; no new TUI entrance |
| Internal Coder, Orchestrator, subject reuse and compensation | Domain intent journal pins the request/token before dispatch and retains it through unknown result and restart; it does not own lifecycle status or bypass Runtime validation |
| Existing TUI Restore/resume path | Selected row's token and exact request retained through the existing flow. Unknown/pending results refresh Session observation and prompt for an explicit same-tuple retry; cancellation does not retry and reports the original tuple. Conflict exits for fresh selection, never exchanges the failed intent. No new TUI Restore entrance |
| Internal Coder, Orchestrator, subject reuse and compensation | Domain intent journal pins the request/token before dispatch and retains it through unknown result and restart. A definitive observation conflict retires only that rejected intent without automatic retry; a later deliberate invocation may pin fresh observation with a fresh request ID. It does not own lifecycle status or bypass Runtime validation |
| Runtime startup / pending reconciliation | Private recovery of the existing persisted Restore owner and operation; not an external unguarded new-intent endpoint |
The Workspace internal intent journal stores client retry identity only. Runtime remains the lifecycle authority; it is not a second Restore state machine, Worker ledger or cross-screen lock.
docs/report/2026-10-06-t701-validation.md
+29
View File
@@ -47,3 +47,32 @@ After those fixes, a full Server run reported **618 passed / 1 failed**, solely
Additional exploratory Runtime feature checks did **not** pass: `--no-default-features` test/check cannot resolve existing unconditional `workspace_request` / `reqwest` imports; the test target additionally references disabled `fs_store`. HTTP-only check also lacks the existing retention and futures dependencies. Inspection of original HEAD confirms those imports/gates already exist; no isolated baseline build was performed for these configurations. These are recorded as failed exploratory checks, not semantic passes or newly supported configurations. The default Runtime configuration, which contains fs-store and ws-server, is exercised in full above. This Ticket does not redesign unrelated Runtime feature gating.
Raw session validation logs are retained under ignored `target/t701-validation/`, not shipped as product source. Immutable published source, independent verdict and any subsequent fix/review evidence belong to the explicit repository Merge Request.
## Independent review and caller recovery fixes
The independent Reviewer recorded `request_changes` on MR `01a11064-502b-7222-9494-b1952fbcb1d5`, source `fdce12a47bdd408e6e1a0275dfb218951f1a2f1f`, for two concrete omitted recovery scenarios. These are implementation defects, not baseline failures:
- **`restore_tui_loses_recovery_identity`:** The existing TUI Resume/Restore flow exited on unknown/pending result and discarded the tuple. It now retains the request throughout that flow, refreshes Session observation without treating GET as settlement, and offers explicit same-tuple recovery confirmation. Each additional POST requires user confirmation. Conflict and terminal rejection do not offer same-intent recovery; cancellation makes no additional POST and reports the original identity. No new Restore entrance, new execution operation, input or automatic retry loop is introduced. New TUI tests use the **real Runtime**, with only execution and lost transport acknowledgements faked, to assert identical target/request and unchanged lifecycle operation ID across transport and reconciliation-required recovery. Runtime is a test-only TUI dependency.
- **`restore_internal_conflict_never_retires_intent`:** A definitive stale conflict now settles only its pinned client intent before returning the original conflict; unknown/pending delivery remains pinned. A later deliberate generic orchestrator/subject invocation can use fresh observation. Fresh generic requests use a new UUID identity, including when two rejected invocations see the same generation, without changing unsettled retry identity. Tests cover both generic domains, ABA between pin and admission, journal restart, no automatic retry, immutable historical identity, repeated same-generation conflict, and preservation/reconciliation of a different admitted pending operation.
The first compile of the new TUI fixture omitted `last_finished_submission_request_id` in two WorkerState snapshots and failed; the fixtures were corrected before the passing focused/full tests below.
Post-fix validation:
| Command | Evidence |
| --- | --- |
| root `cargo check` | Passed |
| TUI focused `backend_worker_picker::tests::resume_` | 5 passed, including 3 new real-Runtime recovery tests |
| Server focused `restore_guard_internal_` | 3 passed, including both new conflict retirement tests and existing unknown/restart recovery |
| `cargo test -p tui -- --test-threads=4` | 334 passed |
| `cargo test -p worker-runtime -- --test-threads=4` | 332 library + 34 binary tests passed |
| First post-fix full Server run | 620 passed / 1 failed: the same inherited stale-checker assertion |
| Post-fix isolated checker | Failed the same assertion; not hidden or treated as a pass |
| Additional post-fix full Server run, same four threads and no skips | 621 library + 11 binary tests passed |
| Formatting / diff whitespace checks | Passed |
The Web/API/Worker/client source is unchanged by this fix; its initial published-source validation above remains applicable. The additional full Server pass does not resolve or erase either post-fix checker failure. Raw fix logs are `target/t701-validation/{tui-recovery-fix-target,server-intent-fix-target,fix-root-check,fix-full-tui,fix-full-worker-runtime,fix-full-yoi-workspace-server,fix-checker-isolated,fix-server-additional}.log`.
### Review tooling boundary encountered
A first builtin Reviewer spawn with read-only delegation was rejected with `Merge Request Reviewer SubWorkers must include writable delegated scope`, despite the read-only source-review role. The accepted configuration kept product source read-only and delegated write/command authority only to isolated ignored `target/t701-review-validation` scratch. The Reviewer did not implement changes or delegate implementation. A clearer API distinction between read-only review source and writable validation scratch would avoid this misleading setup failure.