Abort does not stop a workflow – engine keeps running and overwrites status to 'completed' #8

New Issue

2026-09-08T20:57:20-04:00

jared commented

2026-09-08 20:57:20 -04:00

Overview

POST /api/executions/:id/abort logs an execution_aborted entry, sets status failed, and resolves any pending prompt with null. It does not signal executeWorkflowSteps(). The loop continues: after a prompt returns null the next steps execute normally, subsequent execute steps still send commands to workers, and when the loop finishes it calls updateExecutionStatus(id, 'completed') – flipping the aborted execution back to completed and firing the completion webhook.

For a workflow currently inside a long execute or wait step nothing at all changes until that step finishes.

There is also no way to cancel a command already running on a worker (no cancel message type; worker uses exec without keeping the child handle).

Where

server.js abort route; executeWorkflowSteps() has no abort flag check; executeCommandStep()/wait are not interruptible.
worker/worker.js – no cancel handling.

Suggested fix

Keep an aborted flag in _executionState; check it after every await in the engine and before sending each command; make wait and waitForCommandResult reject on abort.
Add a cancel_command message; worker tracks child processes by command_id and kills the process group.
Make updateExecutionStatus refuse to move an execution out of a terminal state.

## Overview `POST /api/executions/:id/abort` logs an `execution_aborted` entry, sets status `failed`, and resolves any pending prompt with `null`. It does **not** signal `executeWorkflowSteps()`. The loop continues: after a prompt returns `null` the next steps execute normally, subsequent `execute` steps still send commands to workers, and when the loop finishes it calls `updateExecutionStatus(id, 'completed')` – flipping the aborted execution back to *completed* and firing the completion webhook. For a workflow currently inside a long `execute` or `wait` step nothing at all changes until that step finishes. There is also no way to cancel a command already running on a worker (no `cancel` message type; worker uses `exec` without keeping the child handle). ## Where - `server.js` abort route; `executeWorkflowSteps()` has no abort flag check; `executeCommandStep()`/`wait` are not interruptible. - `worker/worker.js` – no cancel handling. ## Suggested fix - Keep an `aborted` flag in `_executionState`; check it after every await in the engine and before sending each command; make `wait` and `waitForCommandResult` reject on abort. - Add a `cancel_command` message; worker tracks child processes by `command_id` and kills the process group. - Make `updateExecutionStatus` refuse to move an execution out of a terminal state.

jared added the bug backend workflow-engine executions priority/high labels 2026-09-08 20:57:20 -04:00

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: LotusGuild/pulse#8