WebSocket connects but no result arrives: track prompt-specific terminal states

Symptoms and scope

A connected socket and accepted queue request are not a result. Check client_id, prompt_id, terminal events and history together.

Error fragments for search; IDs, values and filenames may vary:

execution_error
execution_success
executed
executing

Source-supported context

Official messaging distinguishes start, cache, success, error and interruption; executed is sent only when a node returns a UI update, not for every completed node. POST /prompt can also reject an invalid workflow before queueing, returning error and node_errors instead of prompt_id. The pinned API example separates JSON messages from binary previews and fetches saved outputs through prompt-specific history and /view. Source 1 Source 2 Source 3

Cases to distinguish

1. The socket and submission use different client identifiers, or events from another task are mistaken for this one.

2. The client waits only for executed and ignores cached, no-UI-output or failed paths.

3. A proxy drops the socket, binary previews are parsed as JSON, or a disconnection loses the final event.

Diagnostic sequence

The sequence below is an editorial procedure based on the cited context, not a diagnosis already confirmed for your environment.

Step 1. Check that POST /prompt returned prompt_id; handle error and node_errors as validation failures without waiting on the socket. For accepted prompts, record the submission/socket client_id and filter task events by prompt_id rather than the last global message.

Step 2. Handle success, error and interruption separately, retaining the failing node/reason and stopping the wait on a terminal failure.

Step 3. Use bounded timeouts and reconnect logic. After reconnecting, query the known prompt's history before deciding whether any new submission is necessary.

Step 4. Read the output structures actually returned by the relevant nodes and use /view parameters for saved results rather than assuming one output schema.

Completion check

Every accepted prompt reaches a defined success, error or interruption state; validation failures are reported separately, and reconnecting does not duplicate a task.

Limitations and cautions

Proxy and client-library behavior needs deployment-specific testing. This article is not a server-integrated SDK tested by this site.

Original sources

• ComfyUI execution messages — original record checked 2026-09-21; rechecked 2026-09-25.
• ComfyUI Server API routes — original record checked 2026-09-21; rechecked 2026-09-25.
• ComfyUI v0.37.0 WebSocket API example — checked 2026-09-25.

Sources and pinned API example rechecked on 2026-09-25. The 2026-09-21 dates above record the earlier review. No server-integrated or GPU run, minimum-memory measurement or runtime guarantee is supplied.

Related troubleshooting and guides

• Submit a ComfyUI workflow through its native API and track prompt_id
• Retrieve ComfyUI API outputs from task history and /view
• Queue finishes quickly but no new file appears: check cache and output location