查询执行结果

查询执行结果, "query execution result," is the back half of ComfyUI-RemoteCall and the node with the patience. 上传提交 fires the job and hands you a prompt_id; this node sits on that id, polls the remote instance until the run finishes, then downloads every output file and hands them back to your graph as real IMAGE, VIDEO, and AUDIO tensors. It's the difference between "I submitted a job somewhere" and "I have the images in my workflow."

How it works

Give it 地址 and prompt_id (both wire inputs - plug the address from the check node, the id from 上传提交). It polls GET {address}/history/{prompt_id} every 轮询间隔_秒 (default 1s, 0.5–10) until that prompt shows up in the remote history. Once the run completes it gathers output files from the remote's output nodes, downloads each one through /view into your local output/remote_call folder (with a random prefix so files never collide), and converts them:

• 产物_图像 (IMAGE) - all images stacked into one batch tensor, ready for a Preview Image or Save Image node.
• 产物_视频 (VIDEO) - the first video file as ComfyUI's video type.
• 产物_音频 (AUDIO) - the first audio file decoded to a {waveform, sample_rate} dict via PyAV.

Plus 是否成功 (BOOLEAN - true only when the remote run's status is success) and 消息 (STRING) with a per-type count summary.

The optional inputs that matter

• 节点ID - leave empty to pull outputs from every output node; fill it to grab only one specific node's products. Useful when a workflow emits several images.
• 仅查询一次 - do a single poll and stop. This is the escape hatch for the single-instance workaround (see below): submit, wait, then run this node separately with the saved prompt_id.
• 超时_秒 - default 120, up to 600. If the remote job runs longer, the node bails with "任务可能仍在队列或执行中".

The deadlock you'll hear about

Same rule as everywhere in this pack: the controller workflow should run on instance A and poll instance B. If A submits to A, the submitted job queues behind the running controller and this node waits forever - a genuine deadlock, documented at length in the pack's 流程说明. Two instances and you're fine; one instance and you fall back to the 仅查询一次 two-pass trick.

When it looks broken but isn't

Three things trip people up. First, a remote run that failed still finishes - 是否成功 comes back false and the message says "执行失败", so a red boolean here doesn't mean the node is broken, it means the remote generation failed. Second, if there's no video in the results, you'll get a tiny generated placeholder video rather than nothing - that's why av is a hard dependency (it writes the placeholder). Third, the VIDEO/AUDIO outputs need a ComfyUI build with comfy_extras / the comfy_api video types; on an older install the video output degrades to a plain file path. All three are "working as intended" once you know them.

One bonus: because every pulled file lands in output/remote_call on disk, you can grab the files directly even if the tensor types are being awkward. And the pack caches what it pulled in memory, served back through its own little API - GET /remote_call/outputs?prompt_id=xxx - if you ever want the file list programmatically.

Installing it

It's the seventh node in ComfyUI-RemoteCall, installed the same way as the rest: ComfyUI Manager → search ComfyUI-RemoteCall (or 远程调用), restart, or:

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

requests and av are the dependencies (the av matters here more than anywhere else), no models to download.

Where it fits

This node is why the pack is worth having at all. Submitting work to a remote box is easy; the hard part is getting the results back in a form your workflow can keep using. Query Result closes that loop - poll, download, convert, hand over. Set a generous 超时_秒 for video jobs, remember the two-instance rule, and this node quietly becomes the most valuable one you wired up.