MiniMax H3 Retrieve Tasks (Ace Data Cloud)
Poll ten renders, pay for none
- status
- task_id
- media_urls_json
- first_media_url
- result_json
- trace_id
Queued a batch of MiniMax H3 clips, then closed ComfyUI, then forgot which URLs went where? This is the cleanup node. It takes a list of task IDs and asks the Ace Data Cloud service about all of them in one request - no new generation, no credits, no "run it again and hope" - and gives you one aggregated answer plus a per-task breakdown.
What it does differently from Retrieve Task
Both nodes hit the same endpoint (POST https://api.acedata.cloud/minimax/tasks), but this one hard-codes action: retrieve_batch and does something the single-task node can't: it normalises each returned task separately, then flattens the result. media_urls_json becomes every media URL across the whole batch, first_media_url is the first URL found, and result_json carries a items array - one entry per task ID with its own status and URLs. The aggregate status is derived from those per-item states: pending if any of them is still rendering, succeeded when the whole batch is done.
The important consequence: a bad ID doesn't kill the run. Delete a task out of your history, fat-finger a UUID, pass an ID from another account, and that single item comes back marked failed inside result_json while the rest of the batch resolves normally. Compare that with the single-task node, where a failed task raises an exception and stops the graph. When you have a pile of uncertain IDs, this is the gentler tool.
Also worth knowing: task_id and trace_id come back empty on this node. There is no one task to name. The per-task IDs live in result_json.
The inputs
ids_json is required, and it is strict about it - a real JSON array, one string per ID:
["0f2c…","7ab1…","c93e…"]
Type them one-per-line instead and you get ids_json must be a nonempty JSON array of task IDs. (The ids widget on the List Tasks and Delete Task nodes is more forgiving about line breaks; this one is not. Slightly inconsistent pack, and this is where you notice.)
limit, offset, created_at_min and created_at_max are passed through to the same request, so you can page or window a sweep of your account history rather than naming IDs - treat created_at_* as epoch numbers.
parameters_json is the raw-body escape hatch. You won't need it for lookups; any non-empty named widget overrides the same key inside it.
The outputs
The standard six: status, task_id, media_urls_json, first_media_url, result_json, trace_id. The two you'll actually wire are first_media_url - into MiniMax H3 Load Video for a native ComfyUI VIDEO - and result_json, which is the batch's ledger. If you're picking one clip out of eight, read the URLs out of result_json and paste the winner into the loader by hand; that's less fuss than trying to index a flattened array.
Install
cd ComfyUI/custom_nodes && git clone https://github.com/AceDataCloud/MiniMaxH3ComfyUI
python -m pip install -r requirements.txt
Then restart ComfyUI with ACEDATACLOUD_API_KEY (or ACEDATACLOUD_API_TOKEN) set in the ComfyUI process environment. Manager route: search MiniMax H3, publisher acedatacloud, registry ID ace-minimax-h3. Dependencies are just requests and jsonschema, there's no model to download and no GPU needed - every node in this pack is a thin HTTPS client. The generation and load half of the pack wants ComfyUI 0.39.0+ for the native VIDEO type; this node itself doesn't care.
Troubleshooting
- Everything says pending. H3 renders at 768P or 2K with synced audio and takes real time. This node doesn't poll for you - there's no
wait_secondshere, unlike Retrieve Task - so re-run it in a minute. If you want the waiting done for you, loop the single-task node over your IDs instead. ids_jsonwas ignored. It's all-or-nothing: if the JSON doesn't parse, the node errors before any request goes out. Nothing was charged.- Whole batch fails with an HTTP error. That's the call itself, not the tasks - wrong key, no access to the service, or an account issue. Because this is a read-only call, the client quietly retries a dropped connection three times before giving up, so see the error as meaning something.
- The URLs are stale or you need them again later. Re-querying is free, so the sane habit is to keep task IDs - in the node, in a notes node, in a scratch text file - rather than trying to keep every CDN link alive in your head.
Inputs (6)
| Name | Type | Default | Description |
|---|---|---|---|
| parameters_json | STRING | {} | — |
| limit | STRING | — | |
| offset | STRING | — | |
| created_at_min | STRING | — | |
| created_at_max | STRING | — | |
| ids_json | STRING | — |
Outputs (6)
| Name | Type | Description |
|---|---|---|
| status | STRING | — |
| task_id | STRING | — |
| media_urls_json | STRING | — |
| first_media_url | STRING | — |
| result_json | STRING | — |
| trace_id | STRING | — |