Seedream Retrieve Tasks (Ace Data Cloud)
Check every job you queued last night, in one node
- status
- task_id
- media_urls_json
- first_media_url
- result_json
- trace_id
Queued six variations before bed, closed the laptop, came back to a graph full of task IDs and no idea which ones finished. That's the situation this node is built for. Retrieve Tasks takes a list of task IDs instead of one and returns a single rolled-up answer, which beats wiring six Retrieve Task nodes and squinting at six outputs.
Like its single-task sibling, it's a read-only query: no credits, no new generations, and the transport retries it up to three times if the connection hiccups. If you've ever lost an ID you paid for, this is the node that lets you go back and collect.
Inputs
ids_json(multiline STRING, required) - a JSON array of task IDs as text, e.g.["abc-123", "def-456"]. It must be a nonempty array or the node refuses before the request with "ids_json must be a nonempty JSON array of task IDs." One ID still goes in an array; a bare string won't do.parameters_json(multiline STRING, default{}) - the pack's standard JSON object for any API field not surfaced as a widget. Must be a JSON object, not a list.
This is a lookup by ID, not a listing. There's no "show me all my recent tasks" behavior here - you have to have kept the IDs. The batch action is fixed before the request goes out, so there's nothing to configure about how you're querying; the only thing you control is which IDs.
Outputs, and what the roll-up actually means
You get the pack's usual six strings: status, task_id, media_urls_json, first_media_url, result_json, trace_id.
The aggregation is where you need to pay attention, because it's lossy in a specific way:
statusispendingif any task is still running,failedif none are pending but some failed, andsucceededonly if every single one finished cleanly. One slow job out of twenty makes the whole node reportpending.media_urls_jsonconcatenates the media URLs from all completed tasks, sofirst_media_urlis the first URL of the first finished job - not per-task ordering you can trust at a glance.- The per-task detail lives in
result_json, as{"items": [...]}, each entry carrying its own status, task ID, media URLs and data. A task that errored comes back as a failed item rather than killing the whole call, which is the right call - one bad ID shouldn't hide the other five results.
Note what's not filled in: the top-level task_id and trace_id outputs come back empty for a batch. Don't wire task_id downstream expecting an ID; read the items inside result_json instead. To get actual pictures, take a URL from the items and hand it to Seedream Load Image, or run Retrieve Task per ID when you need one image at a time.
Installing
Same pack, same two minutes - ComfyUI Manager, search Seedream, publisher acedatacloud, package Seedream by Ace Data Cloud, install and restart. Manual route:
cd ComfyUI/custom_nodes
git clone https://github.com/AceDataCloud/SeedreamComfyUI
cd SeedreamComfyUI && python -m pip install -r requirements.txt
Set ACEDATACLOUD_API_KEY (or ACEDATACLOUD_API_TOKEN) in the ComfyUI process environment, restart ComfyUI. Dependencies: requests and jsonschema. Nothing else, no models, no GPU.
Gotchas worth knowing
IDs from another account, or a typo in one, come back as a failed item - check items before you conclude your generation died. A deleted or expired task looks the same as a wrong one.
There's no wait_seconds on this node, unlike the single-task retrieve. It polls once and returns. So a batch where three of ten jobs are still cooking reports pending and gives you no URLs at all, even though seven are done. Run it again in a minute; the query is free. That single-shot behavior is the main reason the batch node is a "check on my queue" tool rather than something you leave polling in a production graph.
And the standing note for this whole pack: it's a wrapper around Ace Data Cloud's hosted Seedream API, holding your key and calling the network as its actual function. Ace Data Cloud has almost no presence in community threads, so there's no informal track record to lean on - verify the publisher in Manager, keep the key in the environment, and keep it out of workflow JSON, screenshots and bug reports.
Inputs (2)
| Name | Type | Default | Description |
|---|---|---|---|
| parameters_json | STRING | {} | — |
| ids_json | STRING | — |
Outputs (6)
| Name | Type | Description |
|---|---|---|
| status | STRING | — |
| task_id | STRING | — |
| media_urls_json | STRING | — |
| first_media_url | STRING | — |
| result_json | STRING | — |
| trace_id | STRING | — |