KIE • Wait for Task

What it is

KIE_Next_Wait_Task takes a KIE task id and blocks until that job finishes, then hands back its state, its result URLs and the raw response. It's the manual counterpart to the automatic waiting that every generation node in this pack already does for itself.

Which raises the obvious question: why would you need it? Because waiting is exactly the part that fails gracefully in the wrong direction. A generation node polls until its timeout_seconds runs out and then raises - but the provider job is frequently still running, and on KIE a resubmit is a second paid call. Reattaching to the job you already paid for, later, with a fresh deadline, is what this node is for. It's also how you collect results from workflows that submitted without waiting: the advanced task nodes return a task_id immediately, and this is the thing you paste it into.

How it works

The node polls KIE's job record endpoint for your task id, starting at 2.5-second intervals and backing off toward roughly 15 seconds per check, until either the job reports success or it fails. Success means the result is returned, with one piece of thoughtfulness worth noting: some providers mark a task successful a moment before the result URLs are persisted, so rather than treating a URL-less success as an error, the node keeps polling through a short grace window before it gives up. Failure is reported with the provider's own reason - its failure message or failure code - rather than a generic message. If the clock runs out first, you get a timeout that names the last known state and progress percentage, which is genuinely useful: "still generating, 80%" is a completely different situation from "nothing has happened for twenty minutes."

Inputs and outputs

Two inputs, and one optional extra:

• task_id - required. The id from an earlier run; every generation node in this pack emits it as an output, and the raw response usually carries it too.
• timeout_seconds - required, default 900, minimum 30, maximum 7200 in 30-second steps. This is your total wait, not a poll interval. For long video jobs, raise it rather than running the node repeatedly.
• config - optional, of type KIE_CONFIG. This is the socket for KIE • Advanced Connection Override, and you only need it when you're deliberately pointing a node at different connection settings than the saved ones. Leave it empty in normal use.

Outputs: state - the job's state as text, the fastest way to see success versus fail. result_urls_json - a JSON array of the result URLs, which is what you feed into a download node. raw_json - the complete provider response, and the place to look when a failure reason doesn't make sense yet. credits_consumed and credits_left - the call's cost and your live balance, both also shown on the node after it runs.

If you just want to know whether something finished without blocking the graph, KIE • Task Status is the sibling for that: one check, returning state, progress and the raw response.

Install

cd ComfyUI/custom_nodes
git clone https://github.com/felipederosilva/ComfyUI-KIE-Nodes-Next
cd ComfyUI-KIE-Nodes-Next && pip install -r requirements.txt

Restart ComfyUI. The pack's dependencies are requests, Pillow, numpy and PyYAML; nothing here needs a GPU or a model download. Windows users can run the one-click installer from the repo's dist/ folder. Manager support is the direction of travel (registry metadata ships under publisher felipeosilva), but a plain clone is the dependable install today.

Since this node talks to KIE, it needs the key: Settings → KIE.ai Nodes Next → Connection, pasted once, validated before it replaces a saved key, and displayed only as a masked fingerprint. KIE_API_KEY in the environment takes priority for headless installs.

The node ships in the KIE Next/Utility/Tasks category alongside the task status and upload/download helpers.

When it misbehaves

An empty or wrong task_id is the usual cause of anything odd - a task id from a different KIE account won't resolve, and a track id isn't a task id. Timeouts are informative rather than mysterious: read the state and progress out of the error, then decide whether to raise timeout_seconds and run it again (cheap - you're only polling) or go digging in raw_json for a failure reason. And don't use this node as a substitute for wiring generation nodes normally; the automatic wait inside each generation node is doing the same job without an extra node on the canvas.