Commit Graph
2 Commits
Author SHA1 Message Date
DottaandPaperclip 75666224d4 fix(native): use the deadline for remote health retries (#18324)
## Thinking Path

> - Paperclip manages agent work and its execution state.
> - Remote Runner processes use health reads to check their saved
process identity.
> - A failed health request cannot prove that the process stopped.
> - Three fast gateway errors can exhaust the old retry limit in half a
second.
> - The caller already gives these reads a shared 30-second recovery
budget.
> - This pull request uses that budget with backoff for read-only
failures.
> - A short gateway outage can then clear without stopping the existing
turn.

## Linked Issues or Issue Description

**What happened?**

A transient HTTP 502 during sandbox process supervision caused an active
native Codex turn to fail. The probe stopped after three attempts, even
when most of its 30-second budget remained. The run reported
`notification_transport_failed` and required workspace recovery.

**Expected behavior**

Retry read-only transport failures within the existing deadline. Keep
process identity conflicts authoritative. Do not repeat a signal after a
lost acknowledgement.

**Steps to reproduce**

1. Start a read-only process verification with a 30-second deadline.
2. Return HTTP 502 from its first three transport reads, then allow the
next read to succeed.
3. The old helper rejects after three reads. The fixed helper returns
the successful observation.

Related repairs: #16451 introduced bounded remote probes. #16835 and
#17799 require proof of process exit before replacement. This change
retains those guards.

## What Changed

- Use the existing absolute deadline instead of a three-attempt limit
for read-only probe failures.
- Back off from 250 milliseconds to two seconds. Clip each request to
ten seconds or the remaining budget.
- Preserve the original error and diagnostic when the deadline is
exhausted. Reject non-finite deadlines before an RPC.
- Add a red/green regression and a repeated-gateway-failure case around
a real listening process.
- Update execution semantics and both recovery maps.

## Verification

- Before the fix: the new probe suite failed two behavioral assertions.
The gateway case returned its HTTP 502 error instead of the later
successful observation.
- After the fix: 75 focused probe, diagnostic, process-supervision and
adoption tests pass. The diagnostic failure tests use a controlled clock
for their full 30-second budget. Their error and redaction assertions
stay unchanged.
- Map alignment and module-boundary checks pass.
- Full workspace typecheck and build pass at final commit
`ddd42f66378ebc36ec1d7e0ca1f45943473561b3`.
- The broader affected suite against disposable PostgreSQL passed 994 of
997 tests; its three startup/database timeouts passed unchanged in
isolation. The initial full default local run encountered embedded
PostgreSQL startup failures and did not complete. The four diagnostic
tests that assumed the old short retry timing now use a controlled clock
without weakening their assertions.
- Incident evidence came from Linux AMD64, Node 24.22.2, Core commit
`0c70cedce9a803bdc201324528abb35e423e7cd0`, native Codex `gpt-6.1-sol`,
and a shared ChatGPT subscription. Two separate runs recorded the same
supervision HTTP 502 within one second.
- A disposable live Daytona sandbox check passed on Linux x86_64 and
Node 24.22.1. Three injected gateway failures recovered in 3.31 seconds
on production source from `e54a355fa179022caaa6854302ff56bd85de0229`
(unchanged by the final test-only commit). The real Node listening
process had one launch, retained its exact identity and saved file
across a second read, and produced a confirmed Stop receipt. Sandbox
deletion succeeded. This is process-supervision integration evidence,
not a Codex task or model execution.
- Fixed-revision hosted acceptance and recovery of the original
conversation require rollout. This PR does not claim either. The
duration of the original provider outage remains unknown.

- Final commit `ddd42f66378ebc36ec1d7e0ca1f45943473561b3`: required `ci
/ verify` and `ci / e2e` checks pass; Greptile is 5/5 with no inline
findings. The separate Paperclip Review service has not completed an
assessment and remains queued. It is not a required branch check.

## Risks

- Persistent fast transport failures cause more read-only requests
within the same deadline. Capped backoff limits their rate.
- Missing or changed identity still returns immediately. Failed health
reads still cannot authorize replacement, process signals, or provider
replay.
- Signal requests still have one attempt. The timeout budget and
execution permissions do not change.
- No schema or package changes.

## Model Used

- OpenAI GPT-6, through Codex, with reasoning, repository inspection,
and shell tool use. The exact deployment model ID and context-window
size are not exposed by this session.

## 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
- [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-30 10:50:49 -05:00
DottaandPaperclip db11d899cf fix(native): recover remote sessions while preserving warm runs (#16451)
## Thinking Path

> - Paperclip is the open source app people use to manage AI agents for
work.
> - Native agents keep remote processes and conversation history across
warm turns.
> - A completed turn can leave handoff authority only in controller
memory.
> - Losing that controller can block a follow-up even while its sandbox
survives.
> - This pull request verifies durable ownership and reconnects the
exact prior process before handing it to the next run.
> - Healthy follow-ups stay warm. Recovery preserves saved work without
replaying a completed turn.

## Linked Issues or Issue Description

**What happened?**

A remote warm turn can finish without suspended backup authority. A
replacement controller rejects that prior owner even when its exact
process and completed checkpoint remain. A single unavailable identity
probe can also stop an otherwise valid reattachment.

**Expected behavior**

Keep healthy follow-ups warm. Recover a completed session after proving
that its controller stopped and that the successor holds current
authority. Reuse compatible processes; otherwise save and resume the
conversation. Retry unavailable identity reads within one shared
deadline.

**Steps to reproduce**

Use `doc/testing-native-remote-continuity.md`. Its Linux cases execute
real turns through PostgreSQL, TLS ingress, and the Rust runner. They
kill a separate controller process, recover old checkpoint metadata, and
change process configuration. The provider is deterministic.

Related: #16432 and #16441 fix live warm-owner handoffs. #16341 adds
recovery diagnostics. #14695 covers provider process retention.

## What Changed

- Preserve warm process reuse between healthy remote turns.
- Verify a committed prior result, stopped controller, matching
checkpoint and sandbox, and current task/coordinator ownership before
recovering an orphaned warm session.
- Reconnect through the prior run route, then use the existing
authenticated run attachment to change authority.
- Persist a process-configuration digest. Close and save recovered
sessions when old or changed configuration cannot support reuse.
- Retry unavailable state, marker, and process reads within one
30-second deadline. Keep signals and definitive identity failures
single-attempt.
- Record closed recovery diagnostics, including unreadable or malformed
saved state.
- Retire the recovery-only ownership check after verified attachment, so
later warm turns use their current authority.
- Add real-process Linux regressions and refusal controls.
- Expose the existing source-only file-recovery form for retained native
holds, with the same board authority, evidence, and exact stop-receipt
requirements as legacy holds. Recording recovered files does not change
task status or replay a run.

## Verification

- `pnpm -r typecheck` passed; the server check was repeated for the
third-turn fix.
- `pnpm build` passed after the final UI change. The UI typecheck, token
gates, and map checks also pass.
- Four Linux continuity cases passed: warm reuse, controller loss,
legacy checkpoint metadata, and changed configuration. Each creates one
conversation and starts exactly three turns, including a healthy
follow-up after recovery. The fixture uses expired prior leases; the
third turn keeps the runner and provider processes.
- Greptile caught the retained recovery gate; the third-turn regression
now covers it. An initial test omitted the heartbeat’s saved input and
left a test process after failure; the fixture was corrected and its
disposable container reset before the passing run.
- The current focused executor/restart group passes all 749 tests,
including the original failure classifications.
- Native file-recovery and UI tests pass (52 tests), including blocked
tasks and both native and legacy holds.
- After merging current master and retaining its equivalent CI
expression check, the CI policy tests pass (15 tests) and all four
three-turn Linux continuity cases pass again on
`dec418ae55ff21b4fb067132613658cce445f181`.
- `pnpm test:run` completed its general server group with 20,572 passes,
103 skips, and three failures: the skill-audit child process and two
HTTP test timeouts. The same three suites then passed in isolation (89
tests) without code changes. That local command stopped before later
groups; the complete final-head CI, including general, serialized,
Runner, build, and browser gates, is green.
- Greptile reviewed the combined head
`dec418ae55ff21b4fb067132613658cce445f181` at 5/5 with no actionable
findings; both earlier findings are resolved. All final-head CI gates
and the security scan passed. Staging deployment and retained-incident
disposition remain deployment acceptance work.

## Risks

- Recovery requires exact durable evidence. Live conflicting
controllers, replacement sandboxes, Stop/pause, and uncertain effects
must remain blocked.
- After controller loss, tool-contract or process-configuration changes
can restart the provider. Normal healthy follow-ups retain their
processes.
- The new idle-recovery path has Linux fake-provider evidence. Live
Codex/OpenCode and retained quarantined-state recovery still need
staging qualification.
- No database schema, telemetry, or runner protocol changes.

## Model Used

OpenAI GPT-6 through Codex, with reasoning, repository inspection, code
execution, and browser tools. The session does not expose a more
specific model version 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 (targeted checks and
isolated reruns; full-run limitation 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 on
`dec418ae55ff21b4fb067132613658cce445f181`
- [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-15 13:26:09 -05:00