Nodes/ComfyUI-exit/Exit when Last Batch
ComfyUI Node

Exit when Last Batch

The node that double-checks before turning the lights off

By watarika·Created 2 years ago·Updated about a year ago· 0
Exit when Last Batch
  • any
    ◄confirm_delay_sec5►
    ◄confirm_attempts2►
    ◄confirm_interval_sec2►
    ◄base_urlhttp://127.0.0.1:8188►
    ◄hard_exittrue►
    ◄http_timeout_sec2►

    This is the smarter sibling in watarika/ComfyUI-exit. Where the pack's other node (Exit ComfyUI) is a countdown timer that kills the process no matter what, this one waits until ComfyUI's queue is actually empty, re-verifies a few times to be sure, and only then shuts down. That makes it the one to reach for on unattended or overnight runs: queue twenty prompts before bed, and the machine frees itself when the last one lands - without murdering the batch that was still pending. The name "Exit when Last Batch" undersells it; "exit when last batch and I checked three times" is closer.

    It landed in v1.2.0 (September 2025) after the pack's original node, and the design is visibly reacting to that one's weakness: it never guesses from a single snapshot.

    How it works

    When the node executes (it's a terminal/output node - no outputs, a dummy any input that you wire to your final node), it calls ComfyUI's built-in HTTP /queue endpoint at http://127.0.0.1:8188/queue. No external extension needed; that API ships with ComfyUI. It reads the pending and running lists and estimates what's left after this run as pending + running - 1, assuming the one running job is itself.

    If that estimate is zero, it doesn't just exit. It schedules a confirmation pass: wait confirm_delay_sec seconds (so saves and post-processing finish), then recheck /queue confirm_attempts times at confirm_interval_sec-second intervals. Only if every recheck comes back zero does it shut down. Any nonzero count, or any failed request, aborts the shutdown and keeps the server alive - the safe side of a mistake. That's the whole point of the paranoia: the queue can look momentarily empty between items, a save can still be flushing, another browser tab can queue something a second later. The rechecks are the feature, not the overhead.

    The inputs that matter

    • any - dummy input, any type. Connect it to the output of your final node (Save Image or similar) so this runs after the real work.
    • confirm_delay_sec (INT, default 5, 0–120) - grace period after the initial "0 remaining" before rechecks start. This is your "let the file actually hit disk" buffer. Don't zero it out.
    • confirm_attempts (INT, default 2, 1–10) and confirm_interval_sec (INT, default 2, 1–60) - how many consecutive zero checks it needs and how far apart. The README's recommendation for local runs: delay 3–5, attempts 2–3, interval 2–3.
    • hard_exit (BOOLEAN, default True) - True forces an immediate os._exit(0); False tries sys.exit(0) instead.
    • base_url (STRING, default http://127.0.0.1:8188) - change it if ComfyUI isn't on localhost:8188 (custom port, remote box, container).
    • http_timeout_sec (INT, default 2, 1–10) - timeout on each /queue fetch.

    The hard_exit trap

    Read the source and one thing jumps out: the shutdown runs in a background thread, and sys.exit(0) inside a non-main thread only ends that thread in Python - it doesn't stop the whole process. So in practice hard_exit=False may well leave ComfyUI running. The author frames it as "normal shutdown if possible," which is the intent, but the mechanism is iffy. If you actually need the server to go down, leave hard_exit=True. If you're on a setup that does its own graceful handling (a wrapper script that watches for the process to close cleanly), test the soft path before you trust it.

    Installing

    Same pack as before: no models, no heavy deps - just requests, which ComfyUI basically always has. Install via ComfyUI Manager (search "ComfyUI-exit") or:

    cd ComfyUI/custom_nodes
    git clone https://github.com/watarika/ComfyUI-exit
    

    Then restart. It's a small bilingual-README pack from a solo dev, and not something people post about on Reddit - treat it as a self-serve utility, and skim the ~150-line nodes.py once before relying on it, since it's one of those nodes that terminates your process.

    Troubleshooting

    • It never exits. Watch the console. The node logs [ExitWhen] lines - if you see "could not determine, abort shutdown," a /queue fetch failed and it deliberately skipped the exit. Bump http_timeout_sec on a slow machine.
    • It exits even though you queued more. You probably didn't run it as a terminal node - make sure any is wired to the last node's output, or it can execute early in the run.
    • It ignores a remote ComfyUI. That's base_url. Point it at the real address.
    • Missing last image. With hard_exit=True, anything still buffered dies with the process. Keep confirm_delay_sec in the recommended 3–5 range.
    Categoryutils

    Inputs (7)

    NameTypeDefaultDescription
    any*—
    confirm_delay_secINT50–120—
    confirm_attemptsINT21–10—
    confirm_interval_secINT21–60—
    base_urlSTRINGhttp://127.0.0.1:8188—
    hard_exitBOOLEANtrue—
    http_timeout_secINT21–10—

    Outputs (0)

    No outputs