flow_stage_bridge_decode_range

Here's the workflow this node belongs to, because it makes no sense on its own. The pack's staged MiniMax H3 system (flow_stage_begin → samplers → flow_stage_end) generates a long video in numbered stages, and each stage commits its latents to disk the moment it finishes. The point of that is memory: one stage samples, its latent gets parked on disk, the models unload, and the next stage starts fresh - so a 15-second multi-scene clip doesn't try to hold the whole run in VRAM. flow_stage_bridge_decode_range is the read-back end of that design. It goes and pulls those parked latents out of a run's directory and hands them to you as lists, so you can decode and inspect exactly the stages you care about.

What it reads

Mechanically it's boring in the best way. You give it a run_id (the string the stage nodes used - default "default"), plus start_id and end_id, a 1-based inclusive range. Same start and end reads one stage; start_id=3, end_id=3 reads stage 3 on both channels; 1 to 5 reads everything that exists in stages 1–5. Reversed ranges get sorted for you, and stages that were never generated are simply skipped - no error, no filler. The node reads both data channels at once (data1 is the first-pass payload, data2 the refined/second-pass one - no channel selector to fiddle with) and returns bridge_latent_data1 and bridge_latent_data2, each a list of LATENT payloads in ascending stage order. One channel being empty doesn't affect the other.

The important design detail is in the name: it decodes range, not pixels. This node never loads a VAE and never turns anything into an image - it just loads the saved payload files and rehydrates them into LATENT dicts with their metadata. VAE decoding is deliberately pushed downstream to View_bridge_tentor, whose job is to decode one payload or an ordered list and merge them. So the standard chain is exactly what the pack documents:

flow_stage_bridge_decode_range → bridge_latent_data1/data2 → View_bridge_tentor.bridge_latent

Where the files live

Where the files live matters if you ever go poking around by hand: <your output dir>/.apt_stage_bridge/<run_id>/, as stage_{ID-1:05d}.safetensors for data1 and stage_{ID-1:05d}_2.safetensors for data2 (stage 1 is file stage_00000). The node prefers the committed payload written when the stage finished, and falls back to the in-progress checkpoint file if a run was interrupted mid-stage - which is a genuinely useful recovery path: crash mid-run, fix the graph, and read the stages that did complete instead of re-sampling them.

Practical notes

Practical things to know:

• It re-runs when it should. The node hashes each stage file's path, mtime and size, so the moment a stage re-commits (or appears) the cached result invalidates and fresh data flows.
• A corrupted file raises rather than being silently skipped - you'll see the error and know to re-run that stage.
• Long runs decode in RAM downstream. flow_stage_bridge_decode_range itself is cheap, but the merge step in View_bridge_tentor holds all frames in memory, so pulling back 15 stages of full-length clips at once can still eat system memory. Read back what you actually want to look at.

Installing it

Install is the one-line pack install:

git clone https://github.com/cardenluo/ComfyUI-Apt_Preset.git

(drop into custom_nodes, then run install.bat) - the same for every node in this pack. This particular node needs nothing extra - no models, no VAE - since all it does is shuffle files around. But it only becomes useful once you're actually running the pack's staged workflow, so if you're here from a random search and have never seen a flow_stage_begin node, that's the missing half of the picture: this is a viewer for a system that samples elsewhere.