Repository navigation
Issue can land permanently blocked on a "recovery owner"/disposition state when the run that created it terminates #12543
Description
Activity
Production confirmation on managed npm
2026.831.1: we accumulated recovery actions fortimed_out,adapter_failed,cancelled,orphaned_running_run, andsuccessful_run_missing_state. Several source issues remainedblockedafter the provider/process condition was healthy again; event-driven agents never saw them.We built a fail-closed external reconciler that restores only when the action evidence names the current assignee/latest scoped terminal run and no newer live run, checkout, retry, or wake exists. This issue is the right platform invariant: recovery ownership/disposition states need a bounded native replay or an actionable owner, not indefinite silent blocking.
We observed a similar recovery stall: an issue remained unable to resume after its earlier execution had ended.
Observed behavior:
No active run or scheduled retry was present.
Subsequent message wakes were deferred with deferred_issue_execution.
Clicking Interrupt showed Interrupt requested, but did not restart execution.
The execution state reported legacy_execution_requires_reconciliation, with inspect_run as the only permitted recovery action.
The recovery-actions endpoint returned no actionable recovery record. The referenced run had been cancelled before starting.
API reads and a subsequent issue-comment write succeeded, but the issue still could not resume.This appears related to the recovery stall described here, although we have not confirmed that it has the same underlying cause. Is the legacy-execution reconciliation state covered by this issue, or should it be tracked separately?
Repro: Observed as a recurring pattern rather than a single deterministic repro.
before the issue's ownership/disposition is otherwise resolved.
Expected: A newly created issue does not become permanently stuck simply because the
process that created it has ended; ownership/disposition should either default sensibly or
be resolvable through normal channels.
Actual: The issue lands
blockedwith a message indicating the platform could notresolve a "recovery owner"/missing disposition and needs one before the issue can continue.
We observed at least two distinct message variants for what appears to be the same
underlying stall condition:
Nothing in the normal workflow resolves this state on its own; it requires an external actor
to detect and intervene (we built our own detector/auto-recovery for this on our side).
Impact: Issues created by short-lived or interrupted automated runs can silently and
permanently stall with no automatic recovery path, and the stall is not consistently
worded, making it harder for any generic detector (ours or otherwise) to recognize
reliably. We had to build client-side auto-recovery/detection for this rather than being
able to rely on the platform recovering or surfacing it clearly.
Environment: self-hosted instance at commit 19be4cf (2026-08-07). Not yet re-verified against latest master.