Seedream Retrieve Task (Ace Data Cloud)

Every generation node in this pack behaves like a queue submission, not a render. You hit Queue, the graph completes, and the node hands you a task_id with status: pending - the image is being made somewhere else. Retrieve Task is the second half of that transaction: you feed it an ID and it tells you whether the job is done, and where the result lives. It's the least glamorous node in SeedreamComfyUI and the one you'll have open in a second tab all the time.

The best part is what it isn't. This is a read-only lookup, so it doesn't consume credits, and the pack's transport layer treats it that way: read-only requests are retried up to three times on a connection failure, while paid submissions get exactly one attempt. None of that matters when the network's fine, and all of it matters on hotel wi-fi.

What it does with your value

Two widgets, plus the usual escape hatch.

• task_id (STRING) - the ID from a generate/edit/decompose node, or an earlier retrieve. Pasted, if you saved it from a log.
• wait_seconds (INT, 0–240, default 0) - how long the node is allowed to wait for the job to stop being pending.
• parameters_json (STRING) - the pack-wide JSON object for API fields not exposed as widgets.

With wait_seconds left at 0 you get a single instant poll: whatever the task's state is right now, that's what you get back, and if it's still running you'll get pending with no media URLs. Set it to 120 and the node polls in a loop - checking, sleeping a few seconds (capped at 5, so it doesn't hammer the endpoint), checking again - until the status leaves pending or the deadline runs out. Then it returns whatever the last poll saw, completed or not. So it never times out into an error; it times out into pending, which you should read as "ask me again."

A non-empty task_id is required. Nothing else in the node can stand in for it.

Outputs

The pack's standard six strings: status (pending, succeeded, failed or partial), task_id, media_urls_json, first_media_url, result_json, trace_id. Finished jobs also show a small text readout on the node itself - status, task ID, and how many media URLs came back - which is handy when you're debugging without a text-preview node wired up.

The wiring is the whole point: first_media_url → Seedream Load Image → Save Image, and result_json → a preview or a save-text node when you want to read the actual response. task_id simply echoes the ID you asked about, so you can chain retrieves or log it as proof of which job this was.

Installing

Manager, as usual for this pack: search Seedream, confirm publisher acedatacloud, package Seedream by Ace Data Cloud, restart ComfyUI. Or:

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 and restart. requests and jsonschema are the only dependencies. There's a ready-made example workflow in the repo (examples/01-configure-and-run.json) that's literally a Retrieve Task node wired to a PreviewAny - it's a template with a placeholder task ID, and it doesn't submit anything paid on its own.

Where it bites

The obvious one: pasting a task ID that isn't yours or doesn't exist. The service answers, the node returns something that isn't the job you wanted, and you burn a few minutes before noticing. IDs are per-account.

The second, and the one that actually costs money: treating a pending result as a failure and re-queuing the generation node. Don't. The submission you already made is still running and has probably already been billed. Query it.

The third is patience as a design constraint. wait_seconds maxes out at 240, which is generous for a small image and short for a large sequential batch - you'll be running this node several times on a heavy job, which is fine, because each run is free. Just remember that a 240-second wait is the node sitting inside your graph doing nothing visible; don't stack one behind every branch of a workflow unless you enjoy staring at a progress bar.

And the pack-level caveat, since this is the node where your key actually gets used: the credential belongs in the environment, never in workflow JSON. Workflow files get shared, screenshotted and pasted into Discord, and a key that travels that way is a key you have to rotate.