Files
PaperClipAI/server
DottaandPaperclip 69ac928d2b fix(runtime): preserve bounded retries after workspace reconstruction (#16696)
## Thinking Path

> - Paperclip is the open source app people use to manage AI agents for
work.
> - An operator can rebuild a destroyed workspace from saved task
attachments.
> - The first reconstruction run must pass current source and execution
checks.
> - A temporary bootstrap failure can create a bounded retry before
provider work starts.
> - The retry has a new run ID, so the first-run-only reconstruction
check rejects it.
> - This change verifies the retry chain back to the approved first run
and keeps current safety checks.

## Linked Issues or Issue Description

Refs #16690.

**What happened?**

After an operator records workspace reconstruction, a safe bootstrap
retry is cancelled before provider startup. The normal retry scheduler
creates the successor. The reconstruction check then rejects its
immediate predecessor because it expects the original failed export run.

**Expected behavior**

A verified automatic retry can continue under the same reconstruction
decision and remaining retry budget. Changed sources, unrelated
executions, uncertain outcomes, pause and later human blocks must still
stop startup.

**Steps to reproduce**

Record reconstruction with a retry budget remaining. Let its first run
fail before provider work starts with recorded bootstrap evidence. Use
the normal bounded retry scheduler and the locked dispatch gate. Before
this change, the scheduler succeeds but dispatch returns false.

## What Changed

- Verify the predecessor chain back to the recovery action's exact first
continuation.
- Check company, task, agent, terminal predecessor state and each
scheduler-owned wake. Reject cycles, foreign parents and forged wakes.
- Exclude only those verified predecessors from the unrelated-newer-run
check. Keep source hashes, original result identity and all current
execution gates.
- Reuse the existing reconciliation proof for failed predecessors. Keep
the original retry limit.
- Add real PostgreSQL scheduler and assembled-heartbeat regressions.
Update the recovery guide and feature map.

## Verification

- The baseline regression failed at final dispatch after the normal
retry scheduler created its successor.
- The corrected focused group passes 133 tests across reconstruction,
retry scheduling and dispatch. It admits two bounded bootstrap retries
and refuses a third. The assembled heartbeat enters the provider once
for an eligible retry and zero times after a controlled post-claim human
block.
- An intermediate negative case exposed missing predecessor-outcome
validation. Reusing the existing reconciliation proof fixes it. Deleted
sources, pause, forged wakes, foreign parents, unrelated runs and new
recovery holds remain refused.
- Full workspace typecheck and build pass on rebased head
`bd301ec8a703fa1cdc9e1db2638440d203e8d57a`. The rebased focused group
passes all 133 tests. All CI gates pass on that exact head, including
general/serialized tests, Runner, build and browser gates. Greptile is
5/5 with no unresolved threads. A clean full local `pnpm test:run` is
running; the local source stays frozen for that run.
- Module boundaries, maps and diff whitespace checks pass. Live staging
acceptance follows the qualified full Cloud deployment.
- The earlier full local run for #16690 failed while files changed and
its PATH hid `lsof`. All five affected suites then passed in a clean
run: 246 passed, three skipped. Those results do not establish a full
local pass for this follow-up.

## Risks

- Retry ancestry is a rare recovery path. Its primary-key reads grow
with the chain and stop at 64 predecessors. Ordinary runs perform no new
ancestry reads.
- Unknown effects and active recovery obligations stay held. This does
not reset budgets, change provider lifecycle policy, grant access or
replay completed actions.
- No schema migration or new API is included.

## Model Used

OpenAI Codex, GPT-6 family, with reasoning, tool use and code execution.
The session does not expose an exact backend model ID or context-window
size.

## Checklist

- [x] I have included a thinking path that traces from project context
to this change
- [x] I have specified the model used (with version and capability
details)
- [x] I have checked ROADMAP.md and confirmed this PR does not duplicate
planned core work
- [x] I have searched GitHub for duplicate or related PRs and linked
them above
- [x] I have either (a) linked existing issues with `Fixes: #` / `Closes
#` / `Refs #` OR (b) described the issue in-PR following the relevant
issue template
- [x] I have not referenced internal/instance-local Paperclip issues or
links (only public GitHub `#NNN` / `github.com/paperclipai/paperclip`
URLs)
- [x] My branch name describes the change (e.g. `docs/...`, `fix/...`)
and contains no internal Paperclip ticket id or instance-derived details
- [x] I have run tests locally and they pass (focused checks; full-run
scope is recorded above)
- [x] I have added or updated tests where applicable
- [x] I have updated relevant documentation to reflect my changes
- [x] I have considered and documented any risks above
- [x] All Paperclip CI gates are green
- [x] Greptile is 5/5 with no open P2s, recommendations, or follow-ups
- [x] I will address all Greptile and reviewer comments before
requesting merge

Co-authored-by: Paperclip <noreply@paperclip.ing>
2026-10-17 23:48:28 -05:00
..