lsm / neokai / 25256793429

82%

push

github

Fix runtime reverting manually reopened/resumed workflow task back to Blocked (#1759)

* Fix runtime reverting manually reopened/resumed workflow task back to Blocked

When a queued workflow handoff message expires, the runtime blocks the
run and task. If the user then recovers the task via the UI (reopen or
resume), `recoverWorkflowBackedTask` correctly reopens the run and
resets node executions — but it did NOT clear the expired/failed pending
messages from the queue. On the next tick, `repairQueuedWorkflowNodeHandoffs`
re-discovered the stale expired messages and immediately re-blocked the
run, making manual recovery impossible.

Fix by:
1. Adding `clearTerminalForRun()` to `PendingAgentMessageRepository` to
   delete expired/failed/delivered rows for a run (preserving pending).
2. Calling it from `recoverWorkflowBackedTask` before the recovery
   transaction, so the next tick has no stale handoffs to trip over.
3. Resetting the in-memory `blockedRetryCounts` counter for the run so
   the auto-retry budget is replenished after recovery.

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>

* Remove unused expiredResult variable in test

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>

* Guard pre-tx cleanup on spaceId ownership check

The clearTerminalForRun() and blockedRetryCounts.delete() side-effects
fire before the transaction validates ownership. A wrong-space caller
could permanently delete messages or reset retry counters. Added
preTxTask.spaceId === spaceId to the guard.

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>

* Also validate run ownership before pre-tx cleanup

A task's workflowRunId could theoretically point to a run in a
different space. Added preTxRun?.spaceId === spaceId to the guard
so clearTerminalForRun() and blockedRetryCounts.delete() cannot
mutate foreign run state.

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>

---------

Co-authored-by: Claude Opus 4.7 <noreply@anthropic.com>

7802 of 10201 branches covered (76.48%)

Branch coverage included in aggregate %.

16 of 16 new or added lines in 2 files covered. (100.0%)

60460 of 84525 relevant lines covered (71.53%)

255.79 hits per line