ComfyUI Node

⏳ Wait For

A fake dependency that fixes ComfyUI's execution order

By NineKey1028·Created 8 months ago·Updated 5 days ago· 4
⏳ Wait For
  • data_input
  • wait_for
  • data_output

ComfyUI doesn't run nodes top-to-bottom. It runs each node the moment its inputs are ready, which is usually exactly what you want - but sometimes it isn't. If node B reads something that node A writes, and B fires before A gets around to it, you get stale data and a confusing workflow. ⏳ Wait For exists for that one situation: it forces a specific node to finish before everything downstream of the wait starts.

The trick is a fake dependency, not a timer

The mechanism is sneakier than the name suggests. The node doesn't sleep, poll, or loop - there's nothing to sleep. It has two inputs:

  • data_input (any type) - whatever data you want to flow through, passed through unchanged.
  • wait_for (optional, any type) - the output of the node you need to have finished first.

data_output just returns data_input. The entire point is the graph edge: by wiring some output from the slow/first node into wait_for, you create a data dependency in the graph, and ComfyUI's executor will not run this node - or anything wired after it - until wait_for's source has actually produced its value. You're telling the executor "pretend my data depends on that other node," and the executor, taking the graph at face value, enforces the order for you.

The any type business is what makes it practical. In ComfyUI that's a wildcard socket that accepts anything, so you can feed any node's output into wait_for - including an output you wouldn't otherwise consume - purely as a sequencing signal. That's the intended use: sacrifice one wire to an input you'll never look at, and get ordering for free.

When you'll reach for it

The pack's own docs point at the clearest real case: 🔍 Workflow Metadata Reader reads prompt text back out of a generated image's embedded workflow, and that read has to happen after the prompt-producing node has run and the image is saved. In ComfyUI's parallel-ish execution, the reader can fire before the prompt node and grab stale or empty data. Wire the prompt node's output into wait_for, put the reader's data through data_input, and the ordering problem disappears. The same pattern applies anywhere you have a read-after-write dependency that the graph doesn't already express.

Honest caveats: this is a workaround, not architecture. It solves ordering problems at the cost of a wire that does nothing but signal, and if you scatter them around a big workflow they get hard to read - the ecosystem already has a documented tension around nodes that loosen type discipline for convenience (see the Anything-Anywhere backlash). Before adding a Wait For, ask whether the real dependency can be wired directly. When it genuinely can't, this is the clean fix.

Install

Part of ComfyUI_Dynamic_TagLoader, so it arrives with the rest of the pack:

cd ComfyUI/custom_nodes/
git clone https://github.com/NineKey1028/ComfyUI_Dynamic_TagLoader.git

Restart ComfyUI. No extra dependencies - the whole pack is plain Python with nothing to install beyond what ComfyUI already provides.

CategoryDynamicTag/FlowControl

Inputs (2)

NameTypeDefaultDescription
data_input*
wait_foropt*

Outputs (1)

NameTypeDescription
data_output*