Executions waiting for user input are invisible in the list; 'Waiting' filter never matches #3

New Issue

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

jared commented

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

Overview

When a workflow hits a prompt step the execution stays in status running. The Executions list therefore shows it exactly like any other running job, and the only way to discover that it is blocked on a human is to open the detail modal. The Status Filter dropdown offers a Waiting option and CSS exists for .status.waiting, but the server never emits a waiting status, so the filter always returns "No executions match your filters".

Where

server.js executePromptStep() and POST /api/executions – status stays running while _executionPrompts holds a resolver.
public/index.html renderFilteredExecutions() / <select id="statusFilter"> – waiting option with nothing to match.
GET /api/executions list endpoint does not expose waiting_for_input (only the detail endpoint does).

Impact

Prompts time out after 60 minutes (PROMPT_TIMEOUT_MS) and the workflow silently continues with null. Operators regularly miss prompts because nothing in the list or the header says "needs your attention".

Suggested fix

Include waiting_for_input: _executionPrompts.has(id) in the list response, or persist a waiting status.
Render a distinct [⏳ waiting] badge in the list and make the Waiting filter use it.
Show a persistent header banner / toast ("1 execution awaiting input") on execution_prompt broadcasts even when the modal is closed.

## Overview When a workflow hits a `prompt` step the execution stays in status `running`. The Executions list therefore shows it exactly like any other running job, and the only way to discover that it is blocked on a human is to open the detail modal. The Status Filter dropdown offers a **Waiting** option and CSS exists for `.status.waiting`, but the server never emits a `waiting` status, so the filter always returns "No executions match your filters". ## Where - `server.js` `executePromptStep()` and `POST /api/executions` – status stays `running` while `_executionPrompts` holds a resolver. - `public/index.html` `renderFilteredExecutions()` / `<select id="statusFilter">` – `waiting` option with nothing to match. - `GET /api/executions` list endpoint does not expose `waiting_for_input` (only the detail endpoint does). ## Impact Prompts time out after 60 minutes (`PROMPT_TIMEOUT_MS`) and the workflow silently continues with `null`. Operators regularly miss prompts because nothing in the list or the header says "needs your attention". ## Suggested fix - Include `waiting_for_input: _executionPrompts.has(id)` in the list response, or persist a `waiting` status. - Render a distinct `[⏳ waiting]` badge in the list and make the Waiting filter use it. - Show a persistent header banner / toast ("1 execution awaiting input") on `execution_prompt` broadcasts even when the modal is closed.

jared added the bug ux frontend backend executions priority/high labels 2026-09-08 20:57:17 -04:00

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: LotusGuild/pulse#3