Kling Retrieve Task (Ace Data Cloud)

Why this is the node you'll use most

Every generation node in this pack is asynchronous. The client forces async: true on the request, so a Kling job comes back in a fraction of a second with nothing but a task ID and a pending status. The render itself is happening on Ace Data Cloud's side, and the clock is running. This node is how you go find out whether it's done.

It's also the cheapest node in the pack: a task lookup is a read-only query, and read-only queries are the only requests the client will retry (three attempts, with backoff). They don't submit work, so they don't spin up a paid task. Which is why this is the one you can safely spam when a clip is taking forever.

One honest caveat: this pack is a niche third-party route to Kling with no real community footprint - a literal corpus search for "Ace Data Cloud" turns up zero threads. Kling the model is discussed constantly; this wrapper isn't discussed at all. Treat it as new code worth reading, and keep the key in the environment.

How it works

You give it a task_id. The client posts {"action": "retrieve", "id": <task_id>} to the tasks endpoint, then normalizes whatever comes back into the pack's standard shape: a status of succeeded, pending, failed or partial, the media URLs it can find, and a cleaned copy of the response.

The interesting widget is wait_seconds (0–240). Set it above zero and the node stops being a one-shot lookup and becomes a small polling loop: it checks the task, and if the status is still pending and the deadline hasn't passed, it sleeps - five seconds at a time - and checks again, up to your ceiling. That ceiling is validated locally; 241 is an error, not a slow request.

Where does the task_id come from? From the generation node's own task_id output, or from the service's request history if you lost it - and yes, you can just wire it across.

Inputs and outputs

Two inputs worth caring about:

• task_id - the ID you're looking up.
• wait_seconds - how long the node is allowed to sit there polling before it hands back whatever it has.

parameters_json is there too, but for a pure lookup you'll normally leave it at {}.

The outputs are the pack's standard six STRINGs: status, task_id, media_urls_json, first_media_url, result_json, trace_id.

The useful wiring is first_media_url → Kling Load Video (or Kling Load Audio) to turn a finished job into a native ComfyUI type. status is worth routing to a PreviewAny while you're figuring a workflow out - a bare STRING with nothing attached is invisible on the canvas, and "did it finish" is exactly what you want to see.

result_json is deliberately sanitized. Request bodies, user IDs, supplier and upstream model names are stripped before you ever see them, and a service-side failure is rewritten to "Operation failed; use the task or trace ID to inspect the request." If you need to open a ticket with the provider, trace_id is the handle they'll ask for.

Install

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

Manager route: search Kling, publisher acedatacloud, package Kling by Ace Data Cloud, Registry ID kling. Just requests and jsonschema. No model files.

The key comes from the process environment, not a widget:

export ACEDATACLOUD_API_KEY=your_key_here   # then launch ComfyUI

The bundled example workflow examples/01-configure-and-run.json is basically this node plus a preview - open it, paste a task ID, run it. It's a config template and won't submit anything paid.

Common issues

"Set ACEDATACLOUD_API_KEY in the ComfyUI process environment and restart." This is the pack's own error text and it's literal. The key has to be in the environment of the running ComfyUI process. Exporting it in a different terminal, or adding it after ComfyUI started, does nothing for the process that's already up. On Windows, setx then a full relaunch.

An empty first_media_url with status: pending is not a failure. It means the render hasn't finished. Either raise wait_seconds or query again later - querying again is free, and the node will keep pointing at the same task.

A failed status is a task outcome, not an HTTP error. The client raises its own error when the service reports a failure, so you may get a red node rather than a failed string. Either way, use trace_id.

Don't confuse this with re-running the job. Retrieving a task ID is a query. Re-queueing the generation node submits a new paid task. If your graph contains both, be deliberate about which one you hit Queue on.