MiniMax H3 Query Task

A generation node in this pack blocks until the job finishes - it submits, then polls every 5 seconds until the task reaches a terminal state. That's convenient right up to the moment something interrupts it: you hit the cancel button, ComfyUI restarts, your laptop sleeps, or the clip outlasts the one-hour default wait budget. The task didn't vanish. It's still sitting in your MiniMax account, and you already paid for it.

MiniMax H3 Query Task is how you get it back. One input - task_id - and it reads the task straight from the API.

What you get

Five outputs. video_url is the point: the result file for a completed generation, ready to hand to Preview Video for a download. enhanced_prompt is populated for Context IR tasks, where the rewritten prompt is the actual product. status tells you where the job stands, and task_type tells you what you're even looking at - generation, h3_context_ir, or regeneration, matching the three kinds of job this pack can create. task_json is the full response, unfiltered, for when you need to see the error the task died with.

There's a seven-day window on this, per the pack's README. Query a task from last month and you'll get nothing back, because MiniMax doesn't keep it. If a clip matters to you, download the file.

Where it earns its place

The obvious case is recovery. Anything you submitted with a task ID is retrievable, and the upstream nodes all emit that ID as an output, so if a workflow run died partway you can read the task_id from the partial execution log and query it in a fresh graph. The alternative is re-submitting and paying twice for the same prompt.

The less obvious case is using a task ID as a data type. You can park IDs in a text node, spit them out of List Tasks, and treat them as handles to work already done - query them, cancel them, look at the raw JSON when you're debugging why a particular prompt keeps failing. It's also the honest way to check whether that "failed" task actually failed, or whether the node just timed out waiting on it.

Because the calls under the hood are GETs, they're the ones that get retried: the client tries three times on transient 429s, 500s, 502s, 503s and 504s, and honours a Retry-After header when MiniMax sends one. A flaky connection on a query is not a lost cause.

A caveat about status

status here is whatever the task reports - queued, running, succeeded, failed or cancelled. It's a string, so don't wire it into a numeric comparison expecting success to be 1. And a queued status means exactly that: nothing has rendered yet, and you should look again in a bit rather than immediately reaching for Preview Video, which needs a real video_url and will error on an empty one.

Note also that query is a plain read. It doesn't resume the polling loop, and it won't wait. That's the trade for it not blocking your queue while you wait on somebody else's render farm - which is the right behaviour, but it does mean a slow task is a "come back later" task here.

Install

It's part of the pack, so:

cd ComfyUI/custom_nodes
git clone https://github.com/magicwang1111/ComfyUI-MiniMax-H3-API

Restart ComfyUI, then cp local.example.json local.json inside the pack folder and add your api_key. Match base_url to the region the key belongs to - https://api.minimax.cn or https://api.minimax.io - or every call fails authorisation. Only requests and Pillow get installed; there are no checkpoints. ComfyUI Manager: search ComfyUI-MiniMax-H3-API.

When it errors

An empty task_id raises immediately rather than posting a query with a blank path - leading and trailing whitespace gets stripped, but whitespace alone counts as empty. An ID that doesn't exist comes back as an API error carrying MiniMax's own message, so read task_json's error before you assume the node is broken.