End Dialog

End Dialog sits next to End Workflow and End Anything in this pack's workflow-control category, but it's answering a different problem: not "how do I return a value from a sub-workflow," but "how does a workflow that runs once per incoming message still behave like it remembers the conversation." A chat bot built on top of ComfyUI (this pack ships nodes for wiring an LLM agent up to QQ, Feishu, and Discord) typically has the workflow re-triggered fresh for every single message that comes in. Without something tracking which conversation a given run belongs to, every message would look like the start of a brand new chat.

What it does

Two required fields, both strings, both simple to describe and both load-bearing: dialog_id identifies which ongoing conversation this run belongs to, and assistant_response is the final reply text the LLM produced for this turn. Wiring both into this node at the end of a workflow is how a per-message run ties its output back to a specific, continuing conversation thread rather than existing in isolation - the id is what lets a later run for the same user or chat pick the conversation back up instead of starting over.

No outputs - like this pack's other end_* nodes, this is a terminal node, marked as an output node so it runs (and does whatever bookkeeping it does with dialog_id and assistant_response) even when nothing downstream is connected to consume anything from it. There's nothing downstream to connect to, by design - its job is finishing the turn, not feeding the next node in this graph.

Where it fits

This node makes most sense paired with whatever node in this pack manages the conversation-history side of a dialog loop - loading prior turns for a given dialog_id at the start of a workflow, so the LLM has context, and this node closing the loop at the end by recording what it just said. If you're building a one-shot workflow that doesn't need to remember anything between runs, you don't need this node at all; it earns its place specifically in chat-bot-style workflows where the same graph gets re-triggered per message and needs continuity across those separate runs.

Installing it

Same install as the rest of the pack, nothing node-specific:

• ComfyUI Manager: search "comfyui_LLM_party", install, restart.
• Manual: cd ComfyUI/custom_nodes && git clone https://github.com/heshengtao/comfyui_LLM_party, then pip install -r requirements.txt from inside the pack folder using ComfyUI's Python, then restart.

Common issues & troubleshooting

Conversation doesn't seem to persist across messages. The most likely cause is an inconsistent dialog_id - if the value you're feeding in isn't stable across separate runs for what should be the same conversation (say, it's accidentally including a timestamp, or it's being regenerated per-run instead of derived from something like a chat/user id), every run looks like a new dialog even though you intended continuity.

Not sure this node is even necessary for your workflow. If you're not building a multi-turn chat bot - just a single-shot "run once, get an answer, done" workflow - you can skip this node entirely and end the workflow with End Workflow or End Anything instead. This one is specifically for the case where a later, separate run needs to know it's continuing something.

Empty or missing assistant_response. Since both fields are required strings with no defaults, make sure whatever LLM node produced the reply is actually wired into this input - an empty string here means whatever gets logged or persisted against this dialog_id will be empty too, which tends to surface later as a conversation that "forgot" what was said.