MiniMax H3 List Tasks (Ace Data Cloud)
Three actions, one node, and a delete button that bites
- status
- task_id
- media_urls_json
- first_media_url
- result_json
- trace_id
Every cloud video workflow needs one node that can answer "what did I already run, and is it done?" - because with a metered API, the alternative to looking it up is paying for it again. List Tasks is that node. It's the Ace Data Cloud tasks endpoint with the action switch exposed, which makes it the one node in this pack you'll keep permanently in a corner of your graph for reference.
The action selector is the whole node
action gives you three choices plus a (from JSON/default) sentinel: retrieve, retrieve_batch, delete. Leave it on the sentinel and the provider's default kicks in, which is retrieve - so if you fill in id and nothing else, you've built yourself a task lookup. Pick retrieve_batch and it behaves like MiniMax H3 Retrieve Tasks (give it ids). Pick delete and it becomes a destructive call, which is the one case where you must also switch confirm on. Yes, the same service call backs the Delete Task node - this pack exposes the action rather than hiding it, and the guard is identical.
The split matters for retries: retrieve and retrieve_batch are read-only, so a dropped connection is retried up to three times and nothing is ever charged. delete is not, so it gets a single attempt. Task queries and media downloads don't create paid work in this service - you can poll as much as you like.
Inputs worth filling in
id - one task ID, the normal lookup.
ids - several IDs. Here the node is friendlier than its sibling: the contract says this field is an array of strings, so the client accepts either a JSON array or one ID per line in the widget. Feels obvious; it is one of the few places in the pack where it is.
limit / offset - page through your account's task history rather than naming IDs. This is the closest thing to a "browse my renders" view that exists in ComfyUI for this service.
created_at_min / created_at_max - window that history by time. The schema calls these numbers, so you're passing epoch-style values, not dates.
confirm - the boolean that unlocks action: delete. Worth being precise about, because it behaves differently than you'd guess: the node writes every widget into the request, and a boolean false still counts as "set", so the toggle always wins over parameters_json. Putting {"confirm": true} in the JSON and leaving the switch off will not delete anything - you'll get "Set confirm to true to perform this deletion or archive operation." Flip the actual toggle.
parameters_json is the raw request body for anything the named widgets don't cover. Any non-empty widget overrides the identical key inside it.
Outputs
The six standard strings: status, task_id, media_urls_json, first_media_url, result_json, trace_id. For a lookup, first_media_url is what you feed to MiniMax H3 Load Video and result_json is where the detail lives - for batch actions, the per-task breakdown is nested in there, and the status output is derived from the statuses inside. For a delete, expect empty URL fields and a succeeded status if the service accepted the request; the node also reports what it did in the on-canvas text output, which is a nice touch on a node whose result is otherwise invisible.
Install
cd ComfyUI/custom_nodes && git clone https://github.com/AceDataCloud/MiniMaxH3ComfyUI
python -m pip install -r requirements.txt
Restart, then set ACEDATACLOUD_API_KEY (or ACEDATACLOUD_API_TOKEN) in the ComfyUI process environment - the node reads it from there at run time and throws a clear error if it's missing. Manager route: search MiniMax H3, publisher acedatacloud, registry ace-minimax-h3. Only requests and jsonschema install; nothing downloads, nothing runs locally, no GPU. Vendor-side pricing for paid actions is on Ace Data Cloud's platform page, and read-only queries here don't touch it.
Troubleshooting
- You deleted something you wanted. There's no undo, the service doesn't keep a recycle bin you can reach from here, and credits aren't refunded. That's why
confirmis a deliberate two-step and why I'd keep this node'sactionpinned toretrieveand use the dedicated Delete Task node when I actually mean it. - Deleting an already-deleted ID returns an HTTP error rather than a cheerful "nothing to do". The provider keeps error text terse on purpose - you get a status code and a nudge to check request history, not the upstream response body.
- A task you know exists isn't in the list. Check
created_at_min/created_at_maxandlimit/offsetfirst; filtering is the usual culprit, not a lost task. - Nothing runs at all. Missing key in the process environment is the number one cause across this whole pack. Set it where ComfyUI actually starts - a shell export in a different terminal, or a
.envthat nothing reads, does nothing.
Inputs (9)
| Name | Type | Default | Description |
|---|---|---|---|
| parameters_json | STRING | {} | — |
| action | COMBO | (from JSON/default) | 4 options: (from JSON/default), retrieve, retrieve_batch, delete |
| id | STRING | — | |
| ids | STRING | — | |
| limit | STRING | — | |
| offset | STRING | — | |
| created_at_min | STRING | — | |
| created_at_max | STRING | — | |
| confirm | BOOLEAN | false | — |
Outputs (6)
| Name | Type | Description |
|---|---|---|
| status | STRING | — |
| task_id | STRING | — |
| media_urls_json | STRING | — |
| first_media_url | STRING | — |
| result_json | STRING | — |
| trace_id | STRING | — |