上传提交

上传提交, "upload and submit," is the node that actually crosses the network. Everything else in this pack is prep - building the workflow text, collecting files, setting values. This is the moment the wire stops being a metaphor: your files get uploaded to the other ComfyUI, the workflow gets patched with them, and a job gets POSTed to its /prompt endpoint. It's the heart of ComfyUI-RemoteCall, and when it works it's almost anticlimactic - you get back a prompt_id and the whole thing moves on.

The inputs

• 地址 (address) - the target instance, defaulting to http://127.0.0.1:8188. More on that default below, because it's a trap.
• 工作流_JSON (STRING) - the API-format workflow, wired in from 工作流上传 or 工作流解析. Must be API format; the parse node is what enforces that.
• 串联输入 (REMOTE_CALL_TRANSFER) - the chain of {节点ID: data} from your Transfer and Param Override nodes.
• 超时_秒 (INT, optional) - default 60, range 10–300. Covers both the uploads and the submit.

How it works

It's a five-step pipeline, and the source is refreshingly direct about it:

1. Normalize the address and parse the workflow into an API-format prompt dict.
2. Walk the chain. A dict value (from Param Override) gets merged straight into that node's inputs - no upload. A tensor (IMAGE or MASK) gets PNG-encoded and uploaded. A string that's a local file path gets read and uploaded; a string that's an http(s) URL is passed through as-is.
3. Uploads go to the target's /upload/image endpoint as multipart form data, with type=input and overwrite=true - same endpoint ComfyUI uses when you drag a file onto the canvas.
4. Inject each returned filename into the right input key of the right node: LoadImage→image, LoadVideo→file, LoadAudio→audio, and so on.
5. POST {"prompt": prompt} to /prompt, and return the resulting prompt_id.

The outputs

• prompt_id (STRING) - the handle for the job you just created. Wire it into 查询执行结果.
• 是否成功 (BOOLEAN) - the submit's verdict, not the job's; the job itself is still running.
• 消息 (STRING) - 已提交 prompt_id=... on success, or the exact reason it failed.

The trap in the default address

That http://127.0.0.1:8188 default is the pack's biggest footgun, and the README warns about it at length. If the target address points at the same instance that's running this controller workflow, you get a deadlock: ComfyUI executes one queue serially, so the job you just submitted queues behind the very workflow that's waiting for it. The query node polls forever and nothing ever runs.

The correct setup is two instances - controller on A, target on B, address filled with B. If you only have one instance, run the submit alone to grab the prompt_id, let the job finish, then run 查询执行结果 separately with that id and 仅查询一次 turned on. It's clunkier, but it breaks the deadlock.

When it fails

Failures are honest and specific: "节点 X 不在工作流中" when a chain entry references a phantom node, "暂不支持注入" for a node type with no upload-style input, JSON parse errors for bad workflow text, and HTTP status plus a snippet of the response body if /prompt refuses the job. And remember the target needs a real output node (Save Image etc.) or there'll be nothing to query later - the submit will still succeed, the history just won't have results.

Installing it

Part of ComfyUI-RemoteCall (Manager → search ComfyUI-RemoteCall or 远程调用), or:

cd ComfyUI/custom_nodes
git clone https://github.com/playboy-dongan/ComfyUI-RemoteCall

Deps are requests and av; no models, no downloads. Once you respect the two-instance rule, this node is the most satisfying link in the chain - it's where the remote call actually happens.