Fixed in 2.6.0-alpha3 by `5ec8d7b8`; filed after the fact so the release notes have a reference. ## Problem Three routes take a pipeline to a terminal status. Only one of them cleans up the outward interrupts the run was holding open. | Route | Inward signals | Outward interrupts | |---|---|---| | In-loop signal cancel (`PipelineSignalPollSubscriber`) | — | cancelled, node `cancel()` hooks first | | Any terminal outcome (`TerminalPipelineSignalReaper`, priority -100) | `cancelInwardSignalsForPipeline()` | **nothing** | | Out-of-band cancels via `PipelineCancellationAnnouncer` — interaction form, trigger overlap policies, session stop, account cancellation, the expired-interrupt reaper | via the reaper | **nothing** | `InterruptManagerInterface::cancelOutwardInterruptsForPipeline()` exists and is covered by unit and kernel tests, but has **no production caller**. The proof that the gap is in current code is a kernel test, not a row count: `TerminalPipelineOutwardInterruptReapTest` drives a pipeline to each terminal outcome through `PipelineCompletedEvent` — exactly what the out-of-band routes announce — and against `2.6.x-dev` the outward interrupt is still `pending` afterwards. ## Impact Once a row is in that state nothing can ever remove it: - `InterruptManager::cleanupOldInterrupts()` is `status <> 'pending' AND changed < :cutoff`, so a pending row is never swept; - `expireOverdueInterrupts()` only sees rows with an expiry, and an interrupt carries none by default — correctly, since a human-in-the-loop prompt should not lapse on a timer. Two further symptoms: - they keep reporting a live `pendingInterrupt` for a run that ended, so a client can offer a resolve affordance for a run nothing will act on; - a retention sweep deleting the finished pipeline would leave them pointing at a row that no longer exists — manufacturing a new dangling-reference population while clearing an old one. ### The stored population, for scale only One development database (4,039 interrupts, 7,045 pipelines) holds **122 pending outward interrupts owned by terminal pipelines** — all without expiry: | Type | Pipeline status | Rows | Created | |---|---|---|---| | `confirmation` | cancelled | 105 | 2026-01-24 … 2026-05-18 | | `schema_form` | cancelled / failed | 10 | 2026-05-21 … 2026-05-28 | | `workflow_execution` | cancelled | 3 | 2026-05-21 … 2026-05-22 | | `pipeline_completion` | completed / cancelled | 4 | 2026-05-21 … 2026-05-22 | This is a **historical** population, not evidence of a live leak: nothing in it was created after 2026-05-28, and the 105-row bulk is one retired interrupt type on pipelines cancelled months ago. It is offered as an upper bound on how many rows a backfill would touch. The behaviour claim rests on the kernel test above. ## Proposed resolution Widen `TerminalPipelineSignalReaper` to reap both directions. Two properties it already has are what make this safe: 1. **The paused guard.** `PipelineCompletedEvent` fires for `paused` too, and on a paused run the outward interrupt is the resume key — cancelling it strands the run exactly as an expired interrupt does (which is why `ExpiredInterruptPipelineReaper` exists). The reaper already returns early on any non-terminal status. 2. **Priority -100.** Subscribers that translate the terminal outcome for a waiting parent have already run, so reaping cannot strand a caller. Lift `PipelineSignalPollSubscriber::cancelOutwardInterruptsWithHooks()` into a shared `OutwardInterruptCanceller` so both paths use one implementation, and each owning node still gets its `cancel()` hook before the status flips. **One outward type is exempt: `InterruptType::PipelineCompletion`.** A sentinel carries the completing pipeline's id but is owned by whoever is waiting for that run — `PipelineCompletionSubscriber` finds it by that same id and resolves it, cascading the outcome to the parent's `WorkflowExecution` interrupt. Cancelling it destroys the only row that can hand the outcome over, and nothing retries a pending sentinel (`recoverStuckSessions()` recovers sessions, not sentinels), so a resolver that failed transiently would turn a row an operator can still resolve from the inbox into a parent that can never resume. The canceller skips the type outright; the priority ordering is a second, independent guard, and `SubPipelineSentinelSurvivesReapTest` pins both. **The 122 stored rows are deliberately not repaired here.** That is a backfill, and backfills are gated with the rest of the data-removal work (#3592454, #3592457). This issue fixes the write path only; the existing rows stay for that decision. ## Related - #3592455 (retention) — these rows are exactly what a sweep would strand. - The sibling `pending_interrupt_id` issue, which is the same class of bug read from the pipeline side.