Qwen Image Retrieve Tasks (Ace Data Cloud)

Same free lookup as the single-task node, except you hand it a list and get one answer back. Two situations where you actually need it: you fired off six generations and want to know which are done, or a connection died mid-submit and you need to find out which jobs exist before you pay for them again. That second one is the README's own warning, and it's the reason to keep this node around even if your happy path never touches it.

It is read-only, so it never starts a job and it's retried on connection hiccups like the other lookups. Nothing here costs credits.

Inputs

• ids_json - a JSON array of task IDs, one string each, multiline: ["3f1c...", "9ab2...", "77de..."]. It has to be a real JSON array. A bare newline-separated list, a trailing comma, or a single bare ID all fail with ids_json must be a JSON array of task IDs. An empty array fails too, and the API contract agrees - it requires at least one item.
• parameters_json - the usual, must be a JSON object, {} will do. The node fixes the batch action for you, so there's nothing to set in here.

There's no wait_seconds on this one, and that's a sensible omission: polling a whole list for minutes would just block your queue.

Outputs, and how they differ from the single-task node

The six outputs keep the same names, which is a little confusing when you mix the two nodes in one graph:

• status is rolled up across everything you asked about. Any task still running makes the whole thing pending; otherwise any failure makes it failed; otherwise succeeded.
• task_id comes back empty. There's no single task to name. People wire it expecting an ID and get nothing.
• media_urls_json is the aggregate - every URL from every finished task, in order, deduplicated.
• result_json is {"items": [...]} with each task's own normalized result attached, so you can match a URL back to the ID that produced it. That's the output to wire into a text node when you're reconciling a half-finished batch.
• first_media_url is just the first entry of the aggregate.

A failed item in the batch doesn't blow up the node - it comes back as a failed entry inside items, which then rolls status up to failed. So unlike the single-task node, this one tells you about failures instead of raising at you. Handy, and a bit inconsistent with its sibling.

Using it

The realistic pattern: submit a few generations, keep their task_id outputs going somewhere visible (a text node, a note, or just the platform's request history), then run this node once with the list to see where things stand. When a task is done, feed its URL to Qwen Image Load Image and carry on.

Don't try to turn this into the delivery node of a batch pipeline. It gives you N URLs, and the loader takes one media_url at a time, so you'd be running one loader per URL anyway. Most people keep the single Retrieve Task node inside the actual image chain and use this one as a dashboard.

Install

Same pack as the other three nodes, so if one is working they all are:

cd ComfyUI/custom_nodes
git clone https://github.com/AceDataCloud/QwenImageComfyUI
python -m pip install -r requirements.txt

Manager route: search Qwen Image, publisher acedatacloud, package Qwen Image by Ace Data Cloud, restart. Same ACEDATACLOUD_API_KEY in the ComfyUI process environment.

Gotchas worth knowing

It's the cheapest way to answer "did I already pay for this?" If a submission dropped on the wire, list the IDs you have and check what came back before re-submitting. There is no retry on a paid write, so this node is the only audit trail you own.

Empty results are ambiguous. A batch that comes back pending with no URLs is fine - nothing has finished yet. A batch that comes back succeeded with fewer URLs than IDs is the case to open result_json for: the per-item results tell you which ID finished with nothing to hand you.

Don't paste your API key or task IDs into a shared workflow. Same rule as the rest of the pack: task IDs are scoped to your account, and workflows get shared.