SAX Debug Controller

SAX_Bridge has a habit of doing a lot of work inside a single node - a detailer that crops, samples, and blends, a loader that builds a whole pipe. That's great for your canvas and terrible for figuring out what actually happened when something comes out wrong. SAX Debug Controller is the master switch that turns on detailed execution logging for every SAX node in the current workflow, so you can finally see the run, not just the result.

It's the simplest node in the pack to understand: one boolean, enabled, default ON. Toggle it, and the whole workflow's SAX nodes start recording what they did. That's the entire UI.

How it works

Under the hood every SAX node already keeps a light execution record of every run - the pack wraps node execution and accumulates it, always. The Debug Controller is what decides whether that record gets reported. Flip it ON and, at the end of the run, the pack flushes a JSONL execution log plus a human-readable flow report to the console, covering every SAX node that executed in that run. Flip it OFF and the records are discarded without output.

The smart bit: because collection is wrapped at the node level, the report isn't dependent on where the Controller sits in the graph. You don't have to wire it before anything, and it doesn't need to run first for the other nodes to be caught - everything is logged regardless of execution order, and the report is assembled at prompt end. It's an output node, so ComfyUI always runs it, and the pack uses a fingerprint trick to make sure it re-evaluates when you toggle it. You just drop it anywhere on the canvas.

When to reach for it

This is a "something's wrong and I need visibility" node, not a leave-it-in-production thing. The obvious case: a Detailer pass that changes nothing, or a Cache node that you suspect isn't speeding anything up. Turn the Controller on, run once, and read the console report to see what each SAX node actually did - which model was in the pipe, what steps/CFG got inherited, whether a cache got applied. Then turn it off and get back to generating.

Pair it with SAX Debug Inspector (shows a single pipe's contents in the node UI) and SAX Assert (fails the run on a bad value) and you've got the full debug trifecta: inspect the state, assert it, and log everything. For anyone building multi-stage SAX workflows - loader → prompt → sampler → upscaler → detailer → finisher - this is the one node that turns "why is my output different" from a guessing game into a log read.

One honest caveat

It logs, it doesn't fix. You'll see exactly where things go sideways, but the report is only as useful as your ability to read it - expect wall-of-text console output on big workflows, and expect it to slow things slightly while it's on. That's the cost of insight. Use it like a debugger, turn it off when you're done, and it'll save you more hours than it costs.