Repository navigation
Recover recurring automations after transient provider errors in reused target threads #4166
Description
The workflow
A recurring agent automation reuses a persistent target thread. If a provider turn fails and leaves that thread in error, the next scheduled dispatch still needs to continue in the same thread and retain a genuine native automation-run context. This request concerns that recovery workflow in bb 0.43.4.
What happens today
At commit 94d77da, isThreadReusable accepts only idle and active. An existing target in error takes the unusable-target path, which calls disableAutomationsForDeletedThread. The fallback run error says missing, deleted, archived, or not runnable, even though error status alone is sufficient to reach that branch. The generic three-consecutive-failure rule is another terminal pause path.
This is a source-derived product request. No production incident, private logs or clean-room reproduction is asserted in this public issue.
What you would expect
- Allow an existing, non-deleted, non-archived target left in
errorby a classified transient provider failure to recover through a new native scheduled run in the same thread. Preserve that new run’s identity and result-submission context; do not replay side effects from an earlier attempt. - Retry classified transient transport, 5xx and accepted-but-not-started failures with capped backoff instead of permanently disabling the recurring automation. Keep terminal handling for verified missing/deleted/archived targets and permanent configuration errors. Manual pauses must remain manual.
- Show a persistent visible degraded or paused indication with the automation, reason, and next retry or needed operator action until recovery.
Context and alternatives
Related: #2635 addressed transient target lookup errors. It does not change the separate status=error branch above. #2680 documents the two pause paths. I searched open and closed issues for this recovery behavior. The existing provider-retry plugin focuses on narrower provider failure classes; the requested product outcome is that a temporary provider failure cannot silently retire a recurring automation.
AGENT GENERATED
Checks
- I searched open and closed issues for the same request.
- If an agent wrote this, the body ends with
> AGENT GENERATED.
Activity
bb-slop-cop commentedon Sep 23, 2026
🚨 SLOP COP 🚨 ·
new-issue-autopilotApplied Type Feature, Priority Medium, Effort High, and labels plugins, automations. No existing classification values were present; all writes were verified.
This requests new recovery policy, classified retries with backoff, and persistent operator-visible status. The recurring-workflow impact warrants Medium priority; coordinated policy and UI design warrants High effort. Final Type is Feature, so reproduction reporting and a fix PR were skipped.
Show why an automation failed (#6005)
matthiasvongrundherr commentedon Oct 26, 2026
I rechecked #4166 against stable 0.47.1 and current main. #5931 adds provider-unavailable retries, and #6005 makes automation failures visible. The release still rejects an
errortarget and permanently pauses after three consecutive automation failures.I have a local follow-up candidate that preserves both fixes, accepts error targets, gives recurring agent automations sole retry ownership, and starts distinct native runs: at most two fast retries (30/60 seconds), then the next regular slot. User pauses and terminal missing/deleted/archived targets or unavailable projects remain protected. The candidate passes 158 Automations and 34 Provider Retry tests, typechecks and both plugin builds. These are isolated SDK checks, not acceptance of an installed app; the investigation report remains private.
One policy question remains before a follow-up PR: #4166 requests transient-only recovery with terminal handling for permanent configuration errors. The candidate instead keeps the regular schedule for other unclassified recurring-agent failures, leaving failures visible until the user pauses or fixes the job. Should the follow-up retain that regular schedule, or stop on unclassified/permanent provider failures? I am keeping the PR unpublished until that distinction is settled rather than declaring this issue fixed just to satisfy the linked-issue gate.
Stop provider failures from retiring recurring automations
Stop provider failures from retiring recurring automations (get-bb#6677)