Debug List (AnotherUtils)
The Debug Node That Finally Shows You What's In That List
- input_list
- STRING
Every ComfyUI user knows the feeling: a node upstream produces a list of indices, or filenames, or mask values, and you have no idea what's actually in it. The UI shows you a wire, not the data. AnotherShowList is the X-ray: connect any list to it, run the graph, and it prints the list to the console and surfaces it as a text output you can preview. It's the most boring node in AnotherUtils (marcoc2/ComfyUI-AnotherUtils) and also one of the most useful - the pack's own index-mapping and sampling nodes produce lists constantly, and this is how you check your work.
How it works
The node takes a wildcard input (*), which means it accepts any type ComfyUI can produce - lists of images, lists of indices, lists of strings, whatever. It normalizes nested lists (when ComfyUI wraps things one layer deeper than you expect, a common INPUT_IS_LIST artifact), converts the result to a readable string, prints it to the console as [AnotherShowList] Displaying: ..., and returns the string both as an output slot and as UI text. Because it's an output node, the text also shows up in the node's own preview on the canvas - no digging through terminal logs required.
The inputs
Just one:
input_list- any list. Note the node forces input rather than offering a widget, because the whole point is to inspect whatever a wire is carrying.
What comes out
A single STRING with the list rendered as text. Feed it to a text display node if you want it visible in a saved workflow, or just read the preview.
Installing it
Standard AnotherUtils install:
cd ComfyUI/custom_nodes
git clone https://github.com/marcoc2/ComfyUI-AnotherUtils.git
Restart ComfyUI, or search "AnotherUtils" in ComfyUI Manager. No models, no dependencies - it's pure Python string handling.
Where people get burned
The one genuine gotcha is nested lists: if the output shows something like [[0, 1, 2]] instead of [0, 1, 2], that's ComfyUI's INPUT_IS_LIST wrapping, and the node flattens one level of it for you - but if the real data is genuinely a list-of-lists (say, per-frame point groups), you'll see the structure intact, which is actually useful. The other trap is expecting it to do something more than print: it's a debug node, not a transformation. If you want to use the string later, wire the output; if you just wanted to see the list, preview it and move on. And one habit worth forming: drop it in front of any pack node that consumes or produces lists (like ImageListSampler or the audio slicers) the first time you use that node, because "what exactly is this list?" is a question you'll only ask once per workflow - after that you'll know.
Inputs (1)
| Name | Type | Default | Description |
|---|---|---|---|
| input_list | * | — |
Outputs (1)
| Name | Type | Description |
|---|---|---|
| STRING | STRING | — |