并发提交｜MiniMax-H3 多模态视频生成

This node looks like a duplicate of the pack's Minimax_H3_V2_Video node - same controls, same model, same everything - except for one detail that changes what it's for: instead of outputting a finished video, it returns a future (a SEEDANCE_VIDEO_FUTURE handle) and runs the underlying generation asynchronously. The name says it: SeedanceConcurrent_..._Submit. It exists so you can fire off several MiniMax-H3 jobs in parallel and collect them together, rather than running the single node ten times and watching each one grind through upload, poll and download while you sit there.

The pack draws a clean line between "submit" and "receive" nodes. This is the submit half; the other half is the pack's 并发接收视频（10 路） (10-way video receiver). You wire this node's future output into one of the receiver's future_1 through future_10 slots, and the receiver waits on all of them and hands you video_1 … video_10 plus a status_json summary.

How it works

Under the hood each submit node just queues the original Minimax_H3_V2_Video node onto a bounded thread pool - 10 workers by default, tunable with the SEEDANCE_VIDEO_CONCURRENCY environment variable from 1 to 10. Every job still does the full real work: upload your reference media, POST to MiniMax's /v2/video_generation, poll the task, download and verify the MP4. What changes is when it does that work. Your inputs are validated synchronously before anything touches the pool, so a bad prompt (or a missing one - MiniMax-H3 requires it) fails at the node instead of poisoning a whole batch.

The receiver is generic, not model-specific, and that's a feature: you can mix submit nodes in the same 10 slots - some MiniMax-H3 jobs alongside Hailuo or Seedance futures - and they'll all be collected by the same receiver.

What it's good for

Batch prompt exploration is the canonical use. Lock one reference image in image1, copy the submit node nine times with different prompt text, connect all ten future outputs to the receiver, and you get ten clips back in roughly the wall-clock time of one. Two honest caveats. First, it saves time, not money - ten clips cost ten clips, and the README's own warning about per-token upload rate limiting applies harder when you're pushing a lot of reference media at once. Second, don't reach for it for a single shot; the plain node is simpler and prints one clean result.

Failure handling is where this earns its keep

Each submit node keeps the skip_error toggle. Turn it on and a failing job returns a placeholder instead of blowing up, so the rest of your batch keeps running. The receiver then has its own failure_mode: raise stops and tells you which slot died; placeholder keeps the healthy slots and gives you a redacted status_json instead of killing the whole workflow. For a 10-video batch you probably want skip_error on the submit side and placeholder on the receive side - one dead slot shouldn't trash nine paid results.

Install and gotchas

Same pack, same install as the base node: ComfyUI Manager (search ComfyUI Seedance), or clone into custom_nodes and install the requests-only requirements. You still need the Seedance API Config node (or SEEDANCE_API_KEY) with a key from api.seedance.nz, and every submitted job is a metered call - keep it cheap until you trust the setup. The seed widget is only a ComfyUI cache key here, as in the base node, so don't expect it to vary the results. And if a batch "hangs," check the receiver first: a future with no receiver is work nobody collects, and it's the most common way people trip on this pattern.