Skip to content

Make Loop resilient to network retry dead-ends and terminal spam - #141

Merged
ByBrawe merged 22 commits into
mainfrom
fix/network-recovery-terminal-guard
Aug 22, 2026
Merged

Make Loop resilient to network retry dead-ends and terminal spam#141
ByBrawe merged 22 commits into
mainfrom
fix/network-recovery-terminal-guard

Conversation

@ByBrawe

@ByBrawe ByBrawe commented Aug 22, 2026

Copy link
Copy Markdown
Owner

Summary

  • keep OpenCode session.status=retry authoritative: stale busy recovery can no longer reinterpret provider retry as idle
  • fail closed when the status SDK itself is unreachable instead of starting a second prompt during a network outage
  • add transient network classification and exponential Loop retry backoff
  • refund logical runCount/lastRunAt when a Loop-owned turn never really starts or is released by the provider-retry watchdog, so outages do not consume --max-runs
  • keep transient infrastructure failures separate from ordinary failureCount / --max-failures
  • after 2 minutes of continuous explicit host retry, abort only the persisted Loop-owned active turn, refund it, and retry with backoff; unrelated user retries are never aborted
  • preserve plain /loop devam et as intentionally infinite
  • for explicit completion-bounded idle loops (bitene kadar, until done, projeyi bitir), require a fresh completion/no-work reply twice before auto-pausing, preventing hundreds of post-completion continuation turns

Evidence motivating this

A real session log showed an explicit devam et bitene kadar ... projeyi bitir loop producing hundreds of identical post-completion turns (project complete, nothing left) and repeated compaction until loop-clear was issued. Separately, current OpenCode versions and historical issues expose both transient network failures that kill a request and provider retries that can remain in retry; Loop must neither drop the job nor double-dispatch.

Safety model

  • retry and unknown status are never stale-recovered to idle by age alone
  • the retry watchdog acts only when a Loop-owned active run exists
  • a transient failed attempt is refunded, not counted as productive work or ordinary failure
  • plain /loop devam et remains unlimited exactly as documented/requested
  • terminal auto-pause applies only to explicit completion-bounded idle loops and needs two current assistant replies containing both completion + no-work signals; any stated next/remaining work resets it

Regression coverage

  • transient classifier/backoff/run refund
  • stale retry never becomes idle
  • failed status reads fail closed
  • plain infinite continuation remains untouched
  • completion-bounded loop pauses only after two terminal/no-work replies
  • Loop-owned provider retry watchdog refunds a max-runs attempt and re-enables the job

Draft until source CI is green and the generated stable src/index.js bundle is synchronized and passes Bundle Gate.

@ByBrawe
ByBrawe marked this pull request as ready for review August 22, 2026 12:57
Copilot AI lite review requested due to automatic review settings August 22, 2026 12:57

Copilot AI left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

@ByBrawe
ByBrawe merged commit 2c939a5 into main Aug 22, 2026
10 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants