MiniMax H3 Cancel Delete Task
The Stop Button, and the Thing That Cleans Up After It
- action
- status
- result_json
Most ComfyUI nodes are about making something. MiniMax H3 Cancel Delete Task is about stopping something you already started - and one of the few places in this pack where that's even possible, because a generation task lives on MiniMax's servers, not in your queue.
One input: task_id. That's it. It hits MiniMax's delete endpoint and returns three outputs: action, status and result_json.
One node, two jobs
The API decides which of the two verbs applies based on where the task is. Submit a task_id for something still queued and it gets cancelled - taken out before it renders. Submit one for a task that already succeeded or failed and it gets deleted instead, cleaning up the record. The node doesn't ask you which you want; it reflects what happened back in action, which is why that output exists at all. Read it rather than assuming.
status is the resulting state, and result_json is the full response body. If MiniMax rejected the request - wrong account, task already gone, ID from someone else's key - result_json is where the reason lands.
When you'd actually reach for this
The obvious case is a runaway job. You fat-fingered fifteen seconds at 2K, or you're three minutes into watching a task poll and you've realised the prompt is wrong. Cancelling it queued saves you the render; cancelling it running stops the waiting. Either way you stop the workflow from sitting there burning time on output you don't want.
The subtler case is housekeeping. Task records are only listable for about seven days, and if you're generating all day, List Tasks filtered to cancelled or failed accumulates noise that makes it harder to find the IDs you care about. Deleting finished records is tidiness, nothing more - but it's the tidiness that makes the other two management nodes usable.
The one thing to be careful about: deletion is deletion. If you haven't downloaded the result video from a succeeded task, don't delete the record until you have. video_url is the handle, and Preview Video is how you convert it into a file on your disk.
What happens on the other end
Worth understanding before you use it, because it's easy to misread as a bug. The generation nodes in this pack poll their task until it reaches a terminal state, and cancelled counts as terminal. So if you cancel a task while the node that created it is still running, that node will not politely return an empty result - the poller sees a non-success terminal status and raises an error with MiniMax's message.
That's correct behaviour. The task genuinely didn't produce a video. But it means "cancel mid-run" looks like a crash in your ComfyUI console, so don't chase a bug that isn't there.
Install
cd ComfyUI/custom_nodes
git clone https://github.com/magicwang1111/ComfyUI-MiniMax-H3-API
Restart ComfyUI, then in the pack folder:
cp local.example.json local.json
Add your MiniMax API key and set base_url to your key's region - https://api.minimax.cn for a China account, https://api.minimax.io for an overseas one. Only requests and Pillow get installed and no models are downloaded, which makes this one of the lighter pack installs you'll do. ComfyUI Manager: search ComfyUI-MiniMax-H3-API.
Practical notes
An empty task_id raises immediately - the node checks before it calls out, rather than sending a request to a blank path.
This is an output node, so it runs whenever you hit execute. If you've wired a text node holding an old task ID into it, every run re-fires the delete. Harmless on an already-deleted record, less harmless if you meant to keep looking at it. Park the ID in a primitive you clear after use, or run it as a one-off.
Inputs (1)
| Name | Type | Default | Description |
|---|---|---|---|
| task_id | STRING | — |
Outputs (3)
| Name | Type | Description |
|---|---|---|
| action | STRING | — |
| status | STRING | — |
| result_json | STRING | — |