Qwen Image Retrieve Task (Ace Data Cloud)
The node you'll run five times per picture
- status
- task_id
- media_urls_json
- first_media_url
- result_json
- trace_id
The generation node in this pack doesn't hand you an image. It hands you a task ID, because the work is happening on someone else's GPU and it isn't done yet. This is the node that turns that ID into a status and, eventually, into URLs.
It's a read-only lookup, and that's the important property: querying a task does not create a new paid job. Spam it as much as you like. Losing the task ID, on the other hand, costs money - so this node is also your recovery tool.
What it does
It POSTs a retrieve request for one task ID to Ace's task endpoint and reports back. wait_seconds is the reason you'd use it over just refreshing the platform website: set it above zero and the node blocks inside the graph, checking, sleeping up to five seconds, checking again, until the task stops being pending or the timer runs out. Max is 240 seconds.
Because it's a read-only call, the client retries it up to three times on a connection hiccup. The "never retry a paid submission" rule that governs the generation node does not apply here.
Inputs and outputs
Three inputs, and only one of them needs thought:
task_id- the ID from the generation node'stask_idoutput, or one you copied out of your request history on the platform. Blank gets youA task ID or supported trace ID is required.wait_seconds- 0 to 240, default 0. Zero means "tell me right now"; that's the setting for re-checking an old job. If you just submitted and want the whole graph to finish in one Queue press, 120–240 is the sane range.parameters_json- same rule as the rest of the pack: it has to be a JSON object.{}is fine.
The outputs are the same six names as the generation node, with different meaning attached: status, task_id, media_urls_json, first_media_url, result_json, trace_id. In practice status is pending while the job runs and succeeded when it's done - a task that fails doesn't return a failed string at all, it raises. Your queue goes red and you go read trace_id.
media_urls_json stays empty until the task completes. That's your signal that nothing downstream should run yet, which brings us to the wiring:
[Qwen Image 3] task_id ──► [Retrieve Task] first_media_url ──► [Qwen Image Load Image] image ──► SaveImage
result_json is worth wiring to a text or preview node when something looks wrong: it's the normalized response, minus the keys the pack deliberately strips before you see them.
Install
Same pack, same procedure - Manager search Qwen Image, publisher acedatacloud, package Qwen Image by Ace Data Cloud, restart. Or:
cd ComfyUI/custom_nodes
git clone https://github.com/AceDataCloud/QwenImageComfyUI
python -m pip install -r requirements.txt
Same ACEDATACLOUD_API_KEY environment variable as the rest of the pack, set in the ComfyUI process and followed by a restart. There's no separate credential for lookups.
Where people get burned
Still pending after 240 seconds isn't a failure. Some generations just take longer. Re-queue the retrieve node on its own - it's free - or nudge wait_seconds upward.
ComfyUI caches node outputs. If you press Queue again with identical inputs, you may get the cached answer from thirty seconds ago rather than a fresh check. Change task_id or wait_seconds by a character to force a real lookup. It's the same caching everyone trips over with seed widgets, just less obvious because nothing on the node visibly changed.
Task IDs belong to your key's account. An ID pasted from a friend's run, or from a different Ace account, won't resolve for you. If a lookup fails, verify the ID came from your own submission first.
Don't leave it at 240 in a workflow you're going to batch. The node blocks the queue while it waits, so a graph that polls for four minutes ties up a slot other jobs could use. For batches, submit everything, then do one pass with the batch-retrieve node.
Errors here are deliberately terse. Task failed. Use its task or trace ID to inspect the service request. - that's all you get, and the omission of the raw payload is intentional. trace_id plus the platform's request history is the only way forward. And if you see an HTTP 401 or 403, it's the key or the balance, not the node.
A dead download link doesn't mean a dead task. If a later node can't fetch the image, re-run this one to pull the current URLs instead of paying for a fresh generation. The lookup is free; the generation isn't.
Inputs (3)
| Name | Type | Default | Description |
|---|---|---|---|
| parameters_json | STRING | {} | — |
| task_id | STRING | — | |
| wait_seconds | INT | 00–240 | — |
Outputs (6)
| Name | Type | Description |
|---|---|---|
| status | STRING | — |
| task_id | STRING | — |
| media_urls_json | STRING | — |
| first_media_url | STRING | — |
| result_json | STRING | — |
| trace_id | STRING | — |