iceboundrock / iceboundrock/AutoForge
REPLAN_REEXECUTE: restore automatic resume for the crash-before-close window with proof-grade evidence
Nobody has claimed this yet.
- Dominant language
- Python
- Stars
- 0
- Forks
- 0
- Avg merge
- 8h 56m
- Merged PRs (30d)
- 40
Description
Context
PR #66 (R11-F1) closed a second-close hole in the replan transaction: at SUPERSEDE_INTENT, an OPEN source PR with no close receipt used to be treated as "the close never ran" and the close was retried. But that is the same evidence as "the close landed, the process died before the receipt comment was published, and a human reopened the PR", and a retry there overrides the human. The fix (376c45f) makes the write reachable from VERIFIED only, and refuses (persisted REJECTED, BLOCKED) every OPEN-at-intent resume, with or without the receipt.
The cost is that a crash in the sub-second window between persisting SUPERSEDE_INTENT and gh pr close landing (or a transient GitHub failure on the close that never landed) now needs a human instead of a resume. This is rare and the block is safe, so this issue is low priority. It is recorded so the next person does not reintroduce the naive retry.
What a safe retry would need
"Retry only if the close never ran" needs evidence that GitHub can give and a human cannot accidentally remove. Two candidate designs, neither implemented:
- Controller-posted pre-close marker. Post
<!-- autoforge-replan-close-intent: <txn id> -->with a separategh pr commentbeforegh pr close, and keep the post-close receipt as is. On resume: OPEN + no intent marker + no receipt => the close was never attempted, retry; OPEN + intent marker + no receipt => ambiguous, block. Costs one extra GitHub write per replan and a fake/client method. Weakness: it turns absence of a comment into a licence for a destructive write, so a human deleting the marker comment re-opens the hole. The repository's existing rule is that absence only ever decides refusals. - Timeline event watermark. Record, at
SUPERSEDE_INTENT, the highest timeline event id on the source PR (or the count ofclosedevents), read beforegh pr close. On resume, aclosedevent beyond the watermark proves a close happened after the intent (ours or a human's; either way the human's reopen is the last word) => block; none => retry safely. Event ids are monotonic and cannot be deleted, so this is proof-grade with no clock comparison. Costs a newGitHubClienttimeline read, a new journal field required atSUPERSEDE_INTENT(which means a protocol bump per AGENTS.md), fake support, and tests.
Relying on gh pr close --comment's internal order (comment then close) to infer "no close comment => no close" is not acceptable: it is a CLI implementation detail, and a future gh reordering would fail open.
Acceptance (if picked up)
- A crash-before-close resume retries exactly once; the R11-F1 scenario (close landed, crash before receipt, human reopen) still blocks with no second close.
- The regressions in
tests/test_replan.py(test_r11f1_*,test_w6_*,test_transient_failure_during_the_close_leaves_recorded_intent) keep their no-second-close assertions. - Any new journal field goes through the protocol-version boundary, not shape-sniffing.
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start with tests/test_replan.py, especially the test_r11f1_, test_w6_, and transient-failure cases, and read the protocol-version guidance in AGENTS.md. Trace the replan journal and GitHubClient paths named in the issue, choose a proof-grade resume design, and verify the acceptance cases without reintroducing a second close.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- github, python
- Domain
- backend, devtools
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Active
- Clarity
- Needs clarification
- Newbie friendliness
- 35/100