KIE • Task Status
The one node you want when a job is just… sitting there
- config
- state
- progress
- raw_json
Every generation node in this pack blocks. You hit Queue, it submits the job to KIE, then it sits there polling until the task finishes or your timeout runs out. Task Status is the opposite: one lookup, answer immediately, no waiting and no charge.
That makes it the node you actually want when something looks stuck, and the partner node to the pack's fire-and-forget mode.
What it does
It reads KIE's task record for a given task_id and returns three things: state, progress and the raw record. Mechanically that's a single GET against KIE's record endpoint - the same call the generation nodes make in a loop, minus the loop. Nothing is submitted, so nothing is billed.
You'll want it in three situations. First, debugging: your image or video node timed out and you'd like to know whether the job died or just got slow before you pay for another attempt. Second, async workflows: KIE • Universal Market Task (Advanced) has a wait_for_completion toggle, and turning it off returns a task_id immediately - this node is how you check on it later. Third, curiosity about a task ID you copied out of a log or an old workflow.
Inputs
task_id is required and is the only thing you have to think about. Wire it from the task_id output of whichever node submitted the job - every generation node in the pack exposes one. Pasting from a log works too, but IDs are long and unforgiving; the socket is safer.
config is optional and expects a KIE_CONFIG connection from the pack's advanced connection node. Normal workflows don't need it - the pack resolves the API key you saved once in ComfyUI Settings, and KIE_API_KEY in the environment overrides that for headless setups. If a tutorial tells you to wire a config into every node, it's describing the legacy way of doing things.
Outputs
state is a string - the provider's own word for where the task is, such as a success or failure state, and it's the field you branch on. progress is an integer percentage, which is honestly the most useful single number in this whole pack: a task crawling at 12% after ten minutes is a different problem from one sitting at 95%, and a task that's been at 0 for a while usually means your input didn't pass validation upstream.
raw_json is the full record as a pretty-printed string, including failure messages when there are any. Wire it into a Show Text node if you want to read it on the canvas rather than in the console; it's verbose, but when a task fails, KIE's reason is in there and it's usually specific.
Note what this node does not give you: native media. It's metadata only. If the task succeeded and you want the file, use the task's url from the original node, or one of the pack's download nodes.
Install
Same pack, same one-time setup:
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, then set your API key once under Settings → KIE.ai Nodes Next → Connection. ComfyUI Manager installs the pack as well - search "KIE.ai Nodes Next". The requirements list is short and light (requests, Pillow, numpy, PyYAML) with no model downloads, since the actual inference happens on KIE's side and every call is metered.
Why it fails, when it fails
A wrong task_id gives you an error saying the record response had no data object, which is KIE's polite way of saying it's never heard of that ID. IDs are per-account and don't survive forever - don't expect a task from six weeks ago to still resolve.
An expired or replaced key gives you an auth failure from the same client that all the other nodes use, so if Task Status is erroring, your generation nodes will too. Start by checking the Connection settings row rather than editing the graph.
And keep the pack's catalog behaviour in mind: it re-reads KIE's live docs at most once a day, so newly added KIE models can appear as nodes after a restart without a plugin update - and retired ones can stop working between sessions. When a task that used to work starts failing at submission, the endpoint is often the thing that changed, not your workflow.
Inputs (2)
| Name | Type | Default | Description |
|---|---|---|---|
| task_id | STRING | — | |
| configopt | KIE_CONFIG | — |
Outputs (3)
| Name | Type | Description |
|---|---|---|
| state | STRING | — |
| progress | INT | — |
| raw_json | STRING | — |