Relationships
#2929 Follow-up action retries ignore the run's abort signal and can outlast a cancel
Opened by hammz · 10/1/2026
Description
Found while planning swamp-club#2918. Follow-up actions retry with maxRetries/delayMs without checking the abort signal (src/domain/models/method_execution_service.ts, around the follow-up retry loop at ~1136-1203 and delay() at ~1201). A method with follow-ups that is cancelled keeps calling execute() with an already-aborted signal and sleeping between attempts.
Impact
A cancelled workflow or model method run does not stop promptly. With the swamp-club#2918 fix, the owning process waits only up to STEP_STOP_GRACE_MS (4 s) after the cancel for its in-flight methods; a method still retrying follow-ups past that is abandoned, so its method-run record can again be left at running when the process exits.
Expected
The retry loop checks the signal before each attempt and before/while sleeping (abortable delay), and stops with an AbortError once the run is cancelled, so the method records itself cancelled.
Closed
No activity in this phase yet.
hammz commented 10/6/2026, 3:19:59 PM
Closing without a fix. Triage confirmed the defect in the code: the follow-up retry loop in processFollowUpActions never checks the abort signal, its delay cannot be interrupted, and an abort is counted as a retryable failure. But the loop cannot be reached in the shipped product. No built-in model returns followUpActions since the EC2 instance model was removed in February, and the extension wrapper (wrapUserExecute in model_kind_adapter.ts) discards them, so the impact described here cannot occur. Rather than harden unreachable code, swamp-club#3078 proposes removing followUpActions entirely.
Sign in to post a ripple.