Add client_id to progress_text binary WS messages

[christian-byrne]

Summary

Add prompt_id to progress_text binary WS messages (eventType 3) for parallel workflow execution support.

Changes

• Add supports_progress_text_metadata feature flag to SERVER_FEATURE_FLAGS
• Extend send_progress_text() to accept optional prompt_id param with auto-resolution from get_executing_context() and last_prompt_id fallback
• When client advertises support, send new binary format: [4B event_type][4B prompt_id_len][prompt_id][4B node_id_len][node_id][text]
• Legacy format preserved for clients without the flag

Wire Format

New (when supports_progress_text_metadata flag is set):

[4B event_type=3][4B prompt_id_len][prompt_id_bytes][4B node_id_len][node_id_bytes][text_bytes]

Legacy (unchanged):

[4B event_type=3][4B node_id_len][node_id_bytes][text_bytes]

Deployment

Can be deployed independently in any order — feature flag negotiation ensures graceful degradation.

Part of COM-12671

API Node PR Checklist

Scope

• Is API Node Change

Pricing & Billing

• Need pricing update
• No pricing update

If Need pricing update:

• Metronome rate cards updated
• Auto‑billing tests updated and passing

QA

• QA done
• QA not required

Comms

• Informed Kosinkadink

[notion-workspace]

Implement: Backend progress_text messages need prompt_id field

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro

Run ID: 68494584-721f-488c-8a03-a775e3f96c3f

📥 Commits

Reviewing files that changed from the base of the PR and between 09e9bdb and 69d3bfa.

📒 Files selected for processing (1)

• server.py

🚧 Files skipped from review as they are similar to previous changes (1)

• server.py

---

📝 Walkthrough

Walkthrough

This PR adds a server feature flag supports_progress_text_metadata and extends progress-text handling to include an optional prompt_id. PromptServer.send_progress_text gains an optional prompt_id and, when the target client advertises the flag, encodes a length-prefixed prompt_id before node_id and text. Call sites were updated to retrieve and pass prompt_id from execution context: client utilities call get_executing_context(), image nodes include prompt_id in hidden outputs, IO/typing exposes PROMPT_ID, and execution/input construction threads prompt_id through get_input_data and sync payloads.

🚥 Pre-merge checks | ✅ 1 | ❌ 2

❌ Failed checks (2 warnings)

Check name	Status	Explanation	Resolution
Title check	⚠️ Warning	PR title mentions 'client_id' but the changeset actually implements 'prompt_id' as the primary feature.	Update title to reflect the actual change: 'Add prompt_id to progress_text binary WS messages' or similar.
Docstring Coverage	⚠️ Warning	Docstring coverage is 36.36% which is insufficient. The required threshold is 80.00%.	Write docstrings for the functions missing them to satisfy the coverage threshold.

✅ Passed checks (1 passed)

Check name	Status	Explanation
Description check	✅ Passed	Description accurately documents the changes including the prompt_id feature, wire format, and feature flag implementation.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

📝 Coding Plan for PR comments

• Generate coding plan

---

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[coderabbitai]

Actionable comments posted: 1

🤖 Prompt for all review comments with AI agents

Verify each finding against the current code and only fix it if needed.

Inline comments:
In `@comfy_api_nodes/util/client.py`:
- Around line 449-452: The lazy import of get_executing_context inside the block
that calls PromptServer.instance.send_progress_text triggers the pipeline linter
import-outside-toplevel warning; either move the import to the top of the module
(add "from comfy_execution.utils import get_executing_context" alongside other
imports) and remove the in-function import so the call in the code uses the
top-level symbol, or if that creates a circular import, keep the lazy import but
add a pylint disable comment (e.g., # pylint: disable=import-outside-toplevel)
immediately above the local import to acknowledge the intentional pattern;
update the code around get_executing_context and
PromptServer.instance.send_progress_text accordingly.

[Kosinkadink]

Getting the prompt_id inside the node is a bit ugly at the moment. Maybe this is worth adding prompt_id as a hidden type, so that the context id can be automatically passed on the HiddenHolder when declared on the node?

[christian-byrne]

We actually need to be sending client_id AND prompt_id, updating PR now.

[guill]

I think we want to avoid binary encoding whenever possible to avoid needing to support a ton of different encodings. IMO we should use the same pattern we use for previews where the format is:

headerLength (4 bytes)
headerJson (headerLength bytes)
payload

Then the headerJson would just look like

{
  "prompt_id": "34522-43453-34534-34534",
  "node_id": "37",
  "text": "Foo bar baz"
}

That allows us to add additional information to the header in the future without supporting a binary version we need to support in perpetuity.

[guill]

Wait a minute, why do we use a binary message at all? This is just sending text, right? We're not sending a binary image or anything where encoding it would bloat the message. Why not just send this websocket message as json text?

[christian-byrne]

Yeah I can convert to json. Only real downside is the LoC for this PR and the need to then change frontend PR and have very different branches for old vs. new format