Wan Retrieve Task (Ace Data Cloud)

What it's for

The generate nodes in this pack are fire-and-forget. You queue a prompt, the API takes the job, and the node hands you back a task_id and a status of pending. That's it. The video doesn't exist yet as a file you can use.

So the real workflow is two-step: submit once, then ask about the job until it finishes. This node is the "ask about the job" half. Two properties make it the half you'll keep in every workflow even after you've deleted the generate node. First, it's read-only, so re-querying the same task doesn't queue a new paid job (the README's own words: read-only task queries and media downloads should not generate a new paid task). Second, it can block for you - up to 240 seconds - instead of you hammering Queue Prompt.

How it works

It POSTs to https://api.acedata.cloud/wan/tasks with {"action": "retrieve", "id": "<your task id>"} and your bearer token, which the pack reads from the ACEDATACLOUD_API_KEY environment variable at run time.

Because this call is read-only, the client allows three attempts on a connection error, with short backoff. That's the opposite of the paid submit path, which is deliberately single-shot - the author does not want to accidentally bill you twice for one timeout.

With wait_seconds above zero, the same call becomes a polling loop: fetch, check status, and if it's still pending and the deadline hasn't passed, sleep up to five seconds and ask again. When the status changes or the clock runs out, it returns.

You'll see pending while it's queued or running, succeeded once there's media, and partial when media came back alongside an error somewhere in the payload. A hard failure doesn't come back as a status value - the node raises Task failed. Use its task or trace ID to inspect the service request., because the pack scrubs upstream error detail on purpose.

Inputs and outputs

Three inputs. parameters_json defaults to {} and you can leave it alone - it exists so you can pass raw API fields the widgets don't cover. task_id is the string you got from the generate node, or from the service's request history. wait_seconds is an INT from 0 to 240: leave it at 0 for a quick "is it done yet" peek, raise it when you want the node to sit and wait.

Six outputs, all strings: status, task_id, media_urls_json, first_media_url, result_json, trace_id. The wiring that matters is first_media_url → the media_url input of Wan Load Video. media_urls_json is a JSON array of every media link found in the payload (deduped), and result_json is the sanitized response if you want to dig with a preview node.

Install

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

Or find it in ComfyUI Manager: search Wan, publisher acedatacloud, package Wan by Ace Data Cloud, then restart. The repo also ships examples/01-configure-and-run.json, a two-node graph that is exactly this node wired to PreviewAny - import it via File → Open and paste a real task ID in place of the placeholder to see what the payload looks like. Then set ACEDATACLOUD_API_KEY in the environment of the ComfyUI process - not in the workflow - and restart, or every node in the pack throws Set ACEDATACLOUD_API_KEY in the ComfyUI process environment and restart. No models download; the only dependencies are requests and jsonschema.

Where people get burned

A blank task_id errors immediately with A task ID or supported trace ID is required. The field is required in the brief for a reason.

pending is not broken. Fresh 1080p jobs sit in the queue a while. Bump wait_seconds or just re-run the node; it costs nothing to ask again.

Media URLs are empty until the task is done. While pending you get an empty first_media_url, and a loader handed an empty URL will stop with "Task is pending" - that's the pack being nice to you, not a bug.

When it fails, it fails quietly. The client strips raw upstream payloads, credential fields and error bodies before you ever see them, replacing messages with "use the task or trace ID to inspect the request." So keep trace_id when you're debugging: it's the handle the service's request history actually understands.

240 seconds is a ceiling on one node run, not on the job. Long generations will simply outlast it.

Task IDs are per-service. An ID from fal, Replicate or Kling will not resolve here.