SetNode Rack (Editable)

SetNode Rack (Editable) is the same rack of setters as its sibling, with one difference that matters: nothing on it is ever filled in or rewritten for you. Every row is named only by its own text field.

The problem it solves

The standard SetNode Rack names each row after the output feeding it, which is a nice trick - rename the output, the variable is renamed, no second place to keep in sync. But it only works when the output has a usable name. The cases where it doesn't:

The output has no authored name at all - a plain node's IMAGE or INT slot - or its label is junk you'd rather not publish as a variable.
The same output needs to feed two differently named variables. On the standard rack two rows reading one output can't publish two different names. Here you can publish UPLOADED_IMAGE and SOURCE_IMAGE off the same image.
The row's value comes from a subgraph output, which can't hold a name of its own on the standard rack.

If you'd rather solve it upstream, label the output you're reading and the standard rack follows that - the author's preferred answer, since it keeps the whole graph consistent. This node is for when that isn't practical.

How it works

Mechanically it's identical to SetNode Rack: rows are wildcard input sockets, and the node publishes their values into the same naming scope KJNodes' Set nodes use. Racks resolve exactly like Set names, so an ordinary KJNodes Get node - or a GetNode Rack - reads an Editable rack row without knowing the difference. The pack is frontend-only in the KJNodes sense: nodes.py holds real stubs written against the newer comfy_api.latest schema API, while the rack behaviour lives in the bundled JS extension, which hooks KJNodes' lookup so rack rows resolve first and every other lookup delegates unchanged.

The one behavioural difference is where the name comes from: your typing, and only your typing.

The inputs and outputs that matter

value_0 (type *, optional) - tooltip: "Row value. Name the row in the field beside it."
No outputs. It publishes; it doesn't return.

Additional rows are created the same way as on the standard rack - drag a value onto the node body, or right-click → Add row - and the rack caps at 99 rows. Right-click → Remove unused rows clears the spares, and the trailing blank row the UI keeps available is not saved into the workflow.

Install

ComfyUI Manager, search ComfyUI-GetSetRacks. Or:

cd ComfyUI/custom_nodes
git clone https://github.com/SparknightLLC/ComfyUI-GetSetRacks
# restart ComfyUI, then hard-refresh the browser tab (Ctrl+Shift+R)

No Python dependencies, no model downloads, no workflow format changes - pyproject.toml lists none. ComfyUI-KJNodes is the companion install: racks render and resolve their own rows without it, but the Get side of the convention is KJNodes', and the extension warns on load if it's missing.

Where people get burned

You now own the spelling. On this node the name you type is the only identity a row has, and a reader has to match it character for character. UPLOADED_IMAGE and Uploaded_Image are two different variables and the second one will silently resolve to nothing.

Two setters, one name, one scope is still ambiguous. Same rule as the standard rack: replace your old Set nodes when you migrate rather than leaving both publishing.

Scope is downwards only. A rack is visible in the current graph and its ancestors, not to a sibling subgraph - the same limitation KJNodes' Set nodes have, and usually the reason a getter's dropdown looks empty.

Frontend-only nodes go where the frontend goes. These are real node types with frontend behaviour, like KJNodes' Set/Get. When a January 2026 ComfyUI frontend update knocked KJNodes' Set/Get out of the node search and made saved workflows error as frontend_only, anything built on the same mechanism was at risk until patched. If a rack misbehaves right after an update, update KJNodes first, then check the browser console for [GetSetRacks] warnings - a failed lookup logs and falls through rather than breaking the graph.

Don't POST one to the API. The Python stubs raise RuntimeError on execution by design; racks are stripped from the prompt the frontend builds, so seeing that error from a hand-written API prompt means you built the prompt wrong, not that the pack is broken.

Which rack should you actually use

Default to SetNode Rack. It names rows for you, it keeps variable names in sync with the outputs they come from, and typed names are the one thing in this workflow that silently rots. Reach for the Editable variant when the rule genuinely doesn't fit - duplicate names off one output, nameless inputs, or subgraph outputs - and know that from then on, matching your Get nodes to your row names is on you.