Wan Retrieve Tasks (Ace Data Cloud)

What it's for

Working with a paid video API changes how you use ComfyUI. You stop running one job and waiting, and start firing a handful of prompts - different seeds, different models, different reference images - then walking away. Which means you come back to a pile of task IDs and no videos.

Wan Retrieve Tasks is the node for that pile. Paste the IDs, get every finished job's media back in one query, and don't resubmit anything. The plural is doing real work here: without it you'd be daisy-chaining single retrieves or, worse, re-running generations you already paid for.

Inputs

Two, and one of them is the whole node.

ids_json is a multiline STRING holding a JSON array of task ID strings: ["abc123", "def456"]. Not a comma-separated list, not whitespace-separated - actual JSON. The node parses it locally before any request goes out, so a malformed list fails instantly with ids_json must be a nonempty JSON array of task IDs. Empty array counts as malformed too. A multi-line array is fine; JSON doesn't care about your formatting.

parameters_json defaults to {} and, for this node, there's nothing to add - its job is just the IDs. Leave it alone.

There's no wait option here, unlike the single-task node. Batch lookup is a snapshot: whatever is ready is ready.

Outputs

Six strings, same six as the rest of the pack's tool nodes: status, task_id, media_urls_json, first_media_url, result_json, trace_id.

The status value is an aggregate, and the rule is worth internalising: pending if any task in the list is still running, failed if any of them failed, otherwise succeeded. So failed doesn't mean the batch produced nothing - it means at least one job died, and the good ones are still in media_urls_json. first_media_url is simply the first link from all of the tasks flattened together, so treat it as a convenience for a single-job batch rather than something meaningful across many.

Two outputs come back empty on purpose: because a batch query has no single task behind it, the node returns blank strings for task_id and trace_id. The per-task identifiers live inside result_json, which is structured as {"items": [...]} with one entry per ID - status, URLs and trace details for each. If you need to know which of your five jobs failed, that's where you look.

How it works

It POSTs {"action": "retrieve_batch", "ids": [...]} to https://api.acedata.cloud/wan/tasks. The action is fixed by the node, not chosen by you, and the call is read-only, which matters for two reasons. First, the transport retries up to three times on connection errors - read-only queries are safe to repeat, unlike the single-shot paid submit path. Second, querying doesn't queue a new paid job.

Each returned item is normalised individually. If one of them comes back in a failed state, the node catches that per-item and records it as a failed entry in the results rather than blowing up the run - so one expired ID doesn't cost you the data from the four that worked.

Install

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

Or ComfyUI Manager: search Wan, publisher acedatacloud, package Wan by Ace Data Cloud, install, restart. Dependencies are requests and jsonschema, nothing else, and no models download. Then put ACEDATACLOUD_API_KEY (or ACEDATACLOUD_API_TOKEN) in the environment of the ComfyUI process and restart - if it's missing you get Set ACEDATACLOUD_API_KEY in the ComfyUI process environment and restart. on the first queue.

Where people get burned

The most common mistake is expecting the node to wait. It won't; there's no wait_seconds here, so a batch that's still cooking returns pending and you queue again - that's normal, not an error, and it's free. Second is stale IDs: a batch that returns failed usually has one bad or expired ID in the list dragging the aggregate down, so read the per-item statuses in result_json before assuming the whole run is dead. Third, the ID list has to be strings in JSON, and quotes matter - [abc, def] is not JSON. Finally, IDs are service-specific: task IDs from another provider's API won't resolve here, they'll just come back as failed items.