Comet 异步图片收取

The submit node fires off the cloud call and returns a ticket. This node - "Comet 异步图片收取" - is where the actual images come home. Drop it in a workflow after your async submit node, run it, and it checks the pack's internal task list for completed image jobs, downloads the results, and hands them back as a normal image tensor you can preview, save, or feed downstream.

The one input that matters is run_count (default 1, up to 50). That's how many completed tasks this run should collect. If your async submit ran with concurrency: 4, it registered four subtasks - a single receive with run_count: 1 collects them together as one batch task, and higher counts pull more tasks from the queue in order.

How it works

Under the hood it does three things in a row:

1. Refresh the task list for image tasks and find the ones marked done (succeeded).
2. Download each ready task's images - either from local cache paths or by fetching the image URLs with a small thread pool, so a batch of images comes down in parallel rather than one at a time.
3. Assemble them into one image tensor and mark the task as downloaded so the same job isn't collected twice.

Outputs are image (the batch tensor) and query_info (a STRING with a status panel - what got collected, how many images, any warnings). The text output doubles as the node's status readout in the UI, so check it when a run "looks empty."

The receiver is a sibling of the submit node, not its downstream. It reads the pack-wide task list, so it works even if you never wired query_info from the submitter into anything. Wire it up as: submit node → (anywhere) → this receiver → your preview or card node.

When there's nothing to collect

If no tasks are ready, the node returns a placeholder image with a clear "暂无可用图片结果" status rather than crashing. That's a feature, not a bug - it means you can re-run the receiver once the cloud finishes, or bump run_count and drain more of a big batch in one go. The node always marks itself changed, so re-running actually re-checks the task list instead of caching a stale result.

Install and the usual caveats

Same pack install - ComfyUI Manager (search "ComfyUI-CometAPI") or git clone https://github.com/jieg9341-lab/ComfyUI-CometAPI into custom_nodes, restart. Only requests/aiohttp dependencies; no models.

Things to know before you lean on it:

• Task state is process-local. If you restart ComfyUI after submitting but before receiving, the in-flight task can be orphaned. Collect promptly, or accept the loss.
• run_count collects completed tasks in order - if a batch had a few failures, the receiver reports them in query_info rather than silently dropping them. Read the text output.
• The images you receive are the ones the cloud actually made - same cost, same filtering, same data-leaves-the-machine reality as the rest of the pack. The async path changes latency, not privacy or price.