Concurrent Submit | Zhenzhen_video_extend

Kling's video endpoint gives you short clips, and short clips are annoying when the good stuff happens after the cut. This node is the extension step: you hand it a video_id from a previous generation, tell it what should happen next, and it asks Kling to continue the clip. The original Comfly_video_extend lives under the pack's Comfly_kling category and calls Kling's videos/video-extend endpoint, polling the task until the extended clip is ready and handing back a new video - with its own fresh ID, so you can chain extensions.

The concurrent wrapper turns that into a batch tool. Instead of waiting synchronously for one extension at a time, it submits to the pack's shared video pool (ten workers) and returns a task. Extend five different clips in parallel, collect them in Concurrent Collect Videos, and the whole batch lands at once.

Inputs that matter

• video_id - the task/video ID of the clip you want to extend. This is a string; you get it from the video node that made the original clip (the original Comfly_video_extend returns it as its second output). There's no socket to wire from - it's the ID, pasted in.
• prompt - what you want the continuation to do. Empty string is technically allowed; you usually want something here.
• api_key, seed, skip_error - standard.

That's the whole input surface. The single output is a COMFLY_VIDEO_FUTURE task.

How it works

Under the ComflyConcurrent.py wrapper, the original class posts to {baseurl}/kling/v1/videos/video-extend, polls the task status until succeed, then wraps the resulting MP4 in a ComflyVideoAdapter - which is the pack's way of turning a remote video URL into something the rest of your graph can consume. The concurrent wrapper just pushes that whole job onto a bounded executor (ten video workers) and returns a future immediately. The collector waits on it, keeps slot order, and reports per-slot status; failure_mode: placeholder turns a failed extension into a blank clip instead of an aborted batch.

One practical note: because the collector only hands you back video output, the new video_id for chaining is harder to grab in concurrent mode than in the synchronous original. If your workflow is "extend, then extend again," you may want the non-concurrent node for that chained path.

Setup

Same one-time install as every node in this pack - ComfyUI Manager (search "Comfyui-zhenzhen"), or:

cd ComfyUI/custom_nodes
git clone https://github.com/T8mars/Comfyui-zhenzhen

No model downloads. You need a Zhenzhen key from ai.t8star.org (overseas) or api.seedance.nz (domestic), and every extension is a paid call - each one charges like a fresh generation.

Gotchas

The most common mistake is pasting a stale or wrong video_id - the endpoint will fail or extend the wrong clip, and there's no preview to catch it. Extensions stack: the README's older MJ video node capped at four consecutive extensions, and this Kling lane has similar practical limits, so a clip that "should" go on forever eventually won't. Timeouts aren't guaranteed failures - check your async task page. And the overseas endpoint needs a reachable proxy from many regions; 443 errors are network, not node.