Require String Before Latent

This is the latent-flavored twin of the pack's RequireStringBeforeImage. Same trick, different cargo: it takes a LATENT and a control string, returns the latent unchanged, and forces ComfyUI to finish producing the string before the latent moves on. If you've got a prompt-composer or a side-effect node that must complete before the sampler consumes a latent - but nothing data-wise connects them - this is the bridge.

It's from artyclaw/artyclaw-comfy, where it lives in the same source file as its image sibling, sharing one design philosophy: add the dependency, don't touch the data.

How it works

Open the hood and there's almost nothing inside, on purpose. The apply method reads control_text (via _ = control_text, explicitly commented as "force dependency") and returns the latent untouched. ComfyUI derives execution order from data flow, so by consuming that string the node guarantees the string's producer runs first - then the latent sails through. No VAE round-trip, no tensor surgery, no data transformation of any kind. It's a pure ordering constraint wearing a latent-shaped coat.

Where you'd actually use it: you want an API-generated prompt or a file-read to finish before the KSampler runs on your latent, and there's no natural data path from that string node to the sampler. This node sits between, consuming the string and the latent, forcing the ordering without disturbing the latent you're about to sample.

Inputs and output

• control_text - the STRING whose producer must run first.
• latent - the LATENT to pass through.

One output, latent, identical to the input. Same caveats as the image version: this node adds timing, not data - the control string's value isn't carried through to anything; if you need its text downstream, wire it separately.

Install

ComfyUI Manager → search ArtyClaw Comfy Nodes, or:

cd ComfyUI/custom_nodes
git clone https://github.com/artyclaw/artyclaw-comfy

Restart. No dependencies.

Where people get burned

The usual trap is expecting the string to influence the latent - it doesn't, it only gates it. Second, the barrier is only as strong as the producer: if the control string comes from a widget or a node that doesn't actually run anything, there's nothing to wait for and the node is a no-op. Third, note that a node that "does nothing" to its data can still sit in a cache-dependent spot: if the string's producer doesn't re-run on a given pass, downstream may not either. If you're deciding between this and the image version, it's purely about which data type sits at the point you need to gate - pick the one that matches the wire you're protecting.