FastH3 V2 · Bind Current Job to Accepted Parent (T8 EXP)

What it is

H3's native clip length is a handful of seconds. Anything longer is segments stitched together, and the moment you stitch, you inherit a question the hobby tooling usually ignores: is this new segment actually a continuation of that accepted one?

This node answers it. It compares the completed two-stage job - via its SHA - against the immediate accepted parent's saved job SHA and the context/model identities, and issues a typed job_binding if they line up. It doesn't write anything, doesn't accept anything, doesn't compose anything. It's the lineage check before the rest of the delivery chain will talk to you.

Segment 0 is the special case: a first segment has no parent, and the node handles that without complaint. Segment 1 is where it earns its keep.

How it works

The parent side comes from the chain of accepted segments the pack keeps for a given chain_id. The child side is your current run: the recipe fingerprint, the handoff attestation proving LOW → lift → HIGH, and the segment index. If the current job's SHA doesn't match what the parent recorded - a different model, a different first frame, a different context window - the binding fails rather than warning.

That's stricter than most long-video tooling, and it's a deliberate reaction to how H3 continuation tends to fail in practice. Two segments with slightly different LoRAs don't produce an obvious error; they produce a seam, usually with a colour or contrast step, and by then you've spent the render. The pack's own docs list "slight seam colour change" as a known limitation of the dual-pass route even with matched settings - which is a pretty good argument for not adding mismatched settings on top.

Ports

Inputs: current_recipe (from the recipe fingerprint node), handoff_attestation (from the handoff attestation node), segment_index (0 or 1), and optional contexts (the continuation contexts you'd wire for segment 1).

Outputs: job_binding (T8_FAST_H3_V2_CURRENT_JOB_BINDING) - which the media-prepare node requires - plus job_sha256, model_id and report_json.

Segment 0 requires no parent, so an empty contexts wiring there is correct, not broken. Segment 1 with contexts unwired is a wiring mistake, and it'll present as a binding failure rather than a missing-input popup.

Why the strictness is the point

There's a real design argument here. A split, resumable pipeline gives you a lot of freedom: render LOW, freeze it, come back tomorrow and run HIGH, iterate on one half. Every one of those freedoms is a chance to accidentally change something you didn't mean to. The pack's answer is a chain of typed identity checks - recipe fingerprint, per-stage attestation, handoff proof, job binding - each of which refuses when the story doesn't hold.

You can find this annoying on day one and grateful on day three, when the alternative would have been quietly shipping a continuation whose first frame came from a different reference image.

Install

ComfyUI Manager → MiniMax H3 Audio T8, or:

cd ComfyUI/custom_nodes
git clone https://github.com/T8mars/comfyui-minimax-h3-audio-T8.git minimax-h3-audio-T8

Fully quit ComfyUI, restart it, refresh the browser - the pack registers its nodes on import, so a soft reload won't show them. The shipped requirements.txt is empty on purpose: base nodes use only what ComfyUI already provides, and the optional EXP features check their own dependencies when used, so nothing here can pip-replace your Torch/CUDA stack. You need a recent ComfyUI with native H3 support, H3 weights in models/diffusion_models, Qwen in models/text_encoders, and both VAEs in models/vae.

When it fails

The usual report is a job SHA mismatch, and the usual cause is real: you edited something between segments. A LoRA strength, the first frame, a dimension, a Relay plan - any of these moves the current job's identity off the parent's. The correct response is a new chain, not a retry. Reusing the parent's receipts with a changed recipe is precisely the thing this node exists to prevent, and the downstream nodes will catch it again anyway.

The other common one is stale ordering: the handoff attestation wired from before the HIGH stage finished. It has to run after both stages. If you see a complaint about the handoff rather than the parent, that's your cue.