Seedance Retrieve Tasks (Ace Data Cloud)

Fifteen clips queued overnight, ComfyUI crashed at 3am, and you have fifteen task IDs in a scratch file and no videos. This node is the recovery path. Paste the IDs in, get the URLs back. It's also how you check on a batch of jobs that are still cooking without opening fifteen retrieve nodes and wiring them all.

Like the single-task retriever, this is a read-only lookup - it queries work that already exists rather than creating any. It costs no credits, and that's the whole reason it deserves to exist rather than being a fifth "how do I get my video back" thread.

How it works

ids_json is the interesting input, and it is emphatically not free-form. It wants a JSON array of task IDs:

["4f1c9e2a-...", "b7d3a11f-...", "0c9e55b2-..."]

Malformed input is caught before any request goes out, with explicit messages: ids_json must contain a JSON array if you fat-finger the brackets, and ids_json must be a nonempty JSON array of task IDs if you leave it blank. Wrapping it as {"ids": [...]} is the mistake people make - that's the API's shape, not this widget's.

One request goes out with action: retrieve_batch, and the response is normalised item by item. A single bad or expired ID doesn't blow up the whole node: that item comes back as a failed stub instead of an exception, so you still get everything that did resolve.

The outputs, and the one that lies to you

The six output names are identical to the other tool nodes - status, task_id, media_urls_json, first_media_url, result_json, trace_id - but batch semantics bend two of them.

status is a roll-up, not a per-task answer. It reads pending if anything in the batch is still running, failed if anything failed and nothing is still running, and succeeded only when every single task came back clean. So "succeeded" here means "all of it", and a single dead ID will hold the whole node at failed while result_json still contains fourteen good clips.

task_id and trace_id come back empty, because a batch has no single ID. Don't wire task_id onward expecting something useful - and if you wired it into the single-task retriever in the hope of a chain, that's the empty-string error you're staring at. What you get instead is everything living in media_urls_json (all the URLs, flattened into one list) and result_json, an object with an items array where each entry carries its own status, task_id and media_urls. If you need to know which clip is which, parse result_json rather than trusting the flat list - the order is whatever the service returns, not the order you typed.

first_media_url is simply the first URL of that flattened list. Handy for a smoke test, useless for a fifteen-clip recovery. The pack's own example workflow wires the equivalent output into PreviewAny, which is a perfectly good way to eyeball what came back without a JSON parser in your graph.

Installing

Manager: search Seedance, pick Seedance by Ace Data Cloud (publisher acedatacloud), install, restart. Manual, as ever:

cd ComfyUI/custom_nodes
git clone https://github.com/AceDataCloud/SeedanceComfyUI
python -m pip install -r SeedanceComfyUI/requirements.txt
export ACEDATACLOUD_API_KEY=your-key   # in the shell that launches ComfyUI

requests and jsonschema, that's it - no local model, no GPU, no ffmpeg install. The key comes from the ComfyUI process environment, and the pack never writes it into your workflow, which is why sharing a batch-recovery workflow is safe.

Where people get burned

There's no wait_seconds on this node. That's intentional - it's a single lookup, not a polling loop. If half the batch is still rendering you'll get pending and no URLs at all, and the fix is to run the node again in a minute rather than waiting harder.

The empty task_id trap. It's the most common "why is my workflow red" moment with this node, and it's purely a naming collision: the outputs are the same six names across the pack, but batch doesn't populate two of them.

Treating the roll-up status as per-item truth. A batch reporting failed is not "your render failed". Read result_json, find the stub, and you'll see it's one ID - usually an old one you deleted, or a typo - while the rest are fine.

One caveat worth stating plainly: this is a third-party pack talking to a reseller endpoint, not a Comfy Partner Node. It holds your key and calls the network as its job description. The source is short and readable, the key stays out of workflow JSON and logs, and the only hosts it touches are the Ace API and the Ace CDN - which is more than you can say for a lot of what lands on the registry.