Wan27 Get Task

Wan27 Submit Generation hands you a task ID and then walks away. This is the node that goes and asks what happened, and it's where the pack's one genuinely surprising design decision lives: the status is the product, and the outputs JSON is empty until the task literally says succeeded.

That's not sloppiness, it's a deliberate refusal to let "queued" look like "finished." Wan 2.7 runs on someone else's GPUs and the model has no local equivalent - nothing here can be run on your card instead - so you're waiting on a queue you don't control. The node makes you look at the status string before you trust anything downstream.

What it does

One GET against the task endpoint with your ID, then three outputs built from the response dict. The source reads status from the task, and only when it equals the string succeeded does it pull the task's outputs list:

outputs = task.get("outputs", []) if status == "succeeded" else []

Anything else returns an empty list. So there is no partial-result state to misread, and no accidental wiring of an in-progress task into a download step.

The input

task_id is a single STRING, default empty, and you wire task_id from the Submit node into it. Type it by hand and you'll get a clear "Provide a nonempty model or task ID" if it's blank; the ID is URL-quoted on the way out, so a pasted ID with odd characters fails cleanly rather than mangling the request.

The three outputs

status is a STRING - the service's own word for where the task is. Compare it, don't assume it. The node doesn't invent a vocabulary for you, and the only value that guarantees output is succeeded.

outputs_json is the outputs list as JSON text, non-empty only on success. These are URL strings, not ComfyUI IMAGE tensors. That's the single most important sentence in this article. People wire this into a face-detail pass or an upscale and get nothing useful, because the pack never downloads anything for you. A URL is a link you fetch yourself; a tensor is what every other node in your graph expects.

task_json is the entire raw response, always. When a status isn't what you hoped for, this is where the actual reason is - read it before re-submitting anything.

How you actually use it

Wire task_id from Submit, wire all three outputs into a text or JSON preview, queue, and read. Then queue again in a bit. The node opts out of ComfyUI's execution cache, so re-running it genuinely re-fetches instead of replaying the last answer - which is exactly what the README means by "re-execute this read node to refresh it."

Keep one thing in mind if it seems to do nothing at all: the brief marks this node as not an output node. In ComfyUI that means it only executes if something downstream needs its result. If status goes nowhere, nothing runs and nothing happens. Give it a preview sink.

Install

It's the same pack, so there's nothing separate to do:

cd ComfyUI/custom_nodes
git clone https://github.com/NotUsingGithub/ComfyUI-Wan27.git

Restart, and set the token in the ComfyUI process environment - this node authenticates too, because every call in the pack does:

export WAN27_ACCESS_TOKEN="your-token-here"

Zero third-party dependencies, zero weights, no model files. It's an HTTP client with an input widget.

Where it bites

Impatience. Hosted video and image generations are not five-second jobs, and there's no built-in poll that waits for you. Queue the read node again later. Don't build a tight loop against the API - it's a metered account, and the client caps each request at a 120-second timeout anyway.

Treating an empty outputs_json as failure. It isn't. It means "not succeeded yet," or "not succeeded." The distinction lives in status and task_json, so check those first. Only after task_json tells you something went wrong is re-submitting the right move - and if you do, reuse the same request_id in the Submit node rather than minting a new one.

Assuming a URL is an image. Download it and load it in your own pipeline if you want to keep working on it. Nothing in this pack converts a hosted result into a tensor.

Forgetting what ends up in history. Task IDs, statuses and output URLs all land in ComfyUI's stored history, and the README warns about exactly this. A task ID on its own isn't a secret, but a shared workflow with someone else's account data in it is more disclosure than most people intend.

The honest verdict on the node: it's a two-line GET with careful output handling, and the care is the point. It won't lie to you about being done, which is more than you can say for most async wrappers in this ecosystem.