iceboundrock / iceboundrock/AutoForge

REPLAN_REEXECUTE: restore automatic resume for the crash-before-close window with proof-grade evidence

Open
#69 0 comments 0 reactions 0 assignees View on GitHub

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:

  1. Controller-posted pre-close marker. Post <!-- autoforge-replan-close-intent: <txn id> --> with a separate gh pr comment before gh 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.
  2. Timeline event watermark. Record, at SUPERSEDE_INTENT, the highest timeline event id on the source PR (or the count of closed events), read before gh pr close. On resume, a closed event 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 new GitHubClient timeline read, a new journal field required at SUPERSEDE_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.

https://claude.ai/code/session_01Rf6sDKamaCusaoESjsjDeu

Contributor guide

No contributing guide indexed for this repository

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. 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

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.