Issue #3251: [Backend] Workflow run recovery capability and receipt contract - #3293
Issue #3251: [Backend] Workflow run recovery capability and receipt contract#3293louis4li wants to merge 2 commits into
Conversation
Expose typed recovery capability facts and routable fork receipt run ids while preserving existing actor-address receipt semantics. Closes #3251 Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: df0cc74dd4
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| RevisionId: seedView.RevisionId, | ||
| DefinitionVersion: Math.Max(0, seedView.DefinitionVersion)), |
There was a problem hiding this comment.
When InlineYaml or InlineSubYamls changes the source definition, this still stamps the new run with the source run's RevisionId and DefinitionVersion. The resulting committed state and recovery capability therefore claim an exact revision that the run did not execute, corrupting provenance and potentially causing later recovery to resolve the wrong definition; preserve these fields only when the effective YAML bundle is unchanged, otherwise resolve or clear the revision identity.
AGENTS.md reference: AGENTS.md:L62-L63
Useful? React with 👍 / 👎.
| if (ContainsAny( | ||
| error, | ||
| "authorization", | ||
| "unauthorized", | ||
| "forbidden", | ||
| "credential", | ||
| "access denied", | ||
| "grant")) |
There was a problem hiding this comment.
When an ordinary tool or business error happens to contain a substring such as grant or configuration (for example, "grant proposal timed out"), this heuristic marks both retry and run-again as ineligible authorization/configuration failures even though recovery may be valid. Because FinalError is free-form display text, classify recovery from a committed typed failure outcome instead of reconstructing business semantics in the projector.
AGENTS.md reference: AGENTS.md:L83-L85
Useful? React with 👍 / 👎.
| if (source == null) | ||
| return new WorkflowRunRecoveryCapability(); |
There was a problem hiding this comment.
For a current-state document materialized before this field existed, source is null and this returns an empty capability whose actions have Unspecified eligibility and no reason. Such terminal historical documents normally receive no further committed event and the normal path does not replay them, so the nested legacy fallback below is never reached; construct both actions as Unavailable/LegacyUnavailable in this branch.
AGENTS.md reference: AGENTS.md:L84-L84
Useful? React with 👍 / 👎.
Review of PR #3293 — round 1Verdict: rework Verdict rationale (one paragraph)The PR adds the requested typed recovery fields and covers several acceptance cases, but two core contract points are not satisfied yet: recovery eligibility is derived from existing FindingsF1 — Recovery capability is classified from existing error text
F2 — Production receipt uses actor id as the new routable run id
What's good
REVIEW_VERDICT:rework:typed recovery still derives from strings and actor id |
Use typed recovery failure facts for eligibility and keep routable run ids distinct from actor addresses. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Review of PR #3293 — round 2Verdict: pass Verdict rationale (one paragraph)The round-2 diff satisfies the issue's backend recovery capability contract with additive typed proto/read-model fields for retry/run-again eligibility, unavailable reason codes, recommended actions, starting step, definition revision/version, output reuse, and cost semantics, and it preserves receipt compatibility while separating routable FindingsNo blocking findings. What's good
Round comparison
REVIEW_VERDICT:pass:typed recovery contract and run-id receipt separation pass |
1 participant
Issue
Closes #3251 — [Backend] Workflow run recovery capability and receipt contract
Implementation summary
See
.implement-loop/runs/implement-issue-3251.md.Stacked-PR position
feat/2026-08-07_issue-3250(previous issue's branch)feat/2026-08-07_issue-3251🤖 Generated by codex-implement-loop. Reviewer is a Claude subagent (see PR comments for round-N review reports).