CD · Retry Policy

Video generation runs fail. OOM on a 10-second clip, a worker that drops, a model load that times out - the question is never whether, it's what happens next. If your retry logic is "queue it again and hope," you're hammering a broken worker with the same request at full speed. CDRetryPolicy is the node that replaces hope with a proper exponential backoff schedule: bounded, deterministic, and emitted as a record you can inspect and reuse.

It's from Continuity Director, a 20-node pack for repeatable AI video production, and it's one of the reliability nodes - the layer that makes long batches survivable. It computes a schedule; it doesn't run it. Think of it as the config for your retry machinery.

What you set

• max_attempts - 1 to 100, default 4. Total attempts, not retries.
• base_delay_seconds - the first wait, default 2.
• multiplier - the growth factor, 1 to 10, default 2. Classic exponential backoff doubles the wait each time.
• max_delay_seconds - the ceiling, default 60. The wait grows until it hits this and then stays. This is the "bounded" in "bounded exponential."

How it works

The node generates a list of delays between attempts: base, base×multiplier, and so on, capped at the ceiling. It's fully deterministic - same four inputs, same schedule, byte for byte - and the delays are rounded to microseconds so the record is clean. It also guards its own inputs: attempts are clamped to range, the multiplier is clamped to 1–10, and non-finite numbers are rejected rather than silently becoming "wait forever."

Outputs: retry_policy (a CD_RETRY_POLICY wire for other reliability nodes), retry_policy_json (the full schedule - delays_seconds is the list you'll actually consume), and first_delay_seconds (a float, the first wait, handy for a quick check without parsing JSON).

Installing it

Continuity Director installs with zero friction: no model downloads, no API keys, and requirements.txt is a comment declaring no mandatory Python dependencies. Pure standard library, so nothing to conflict with your environment. Search "Continuity Director" in ComfyUI Manager and restart, or:

cd ComfyUI/custom_nodes
git clone https://github.com/xinjian0101/continuity-director.git ComfyUI-ContinuityDirector

Restart ComfyUI - nodes appear as CD · ..., plus a Continuity Director sidebar with an "Add starter chain" scaffold. Update with git pull.

The honest take

Know what this node is and isn't. It's a policy, not a scheduler - nothing here actually retries anything, watches a queue, or waits. You wire the retry_policy_json (or first_delay_seconds) into your own retry logic, or into a queue system that consumes schedules. That makes it feel thin on its own, and it genuinely is a utility node - but the determinism is the point: every consumer of the policy sees the same numbers, and the policy itself is hash-linked like everything in the pack, so "which backoff were we using on that run" is an answerable question. If you've ever debugged a batch where two workers retried on different schedules, you'll get why a single, reproducible policy beats scattered retry code.