DDM Get Node

If you've ever stared at a workflow where one wire snakes across the whole canvas just to feed a value from a workflow you finished three groups ago, you know the pain. DDM Get Node is the retrieval half of a two-node trick: its sibling DDM Set Node stashes any value under a name, and this node pulls it back out anywhere else on the graph. No connection line, no routing through the middle of everything.

The name is almost a lie - nothing about it is "getting" anything from a model or an API. It reads from a plain Python dictionary living inside the ComfyUI server process, keyed by whatever id string you type. The flow is: DDM Set stores the value under "my_latent", DDM Get with the same id hands it back. That's the whole mechanism. You get to treat the workflow like it has variables instead of only wires.

What you set

The node has exactly one input, and it's the one that matters:

• id (STRING, default "value") - the name you gave the value on the Set side. Case-sensitive, so "MyLatent" and "mylatent" are different keys. Use descriptive names like "prompt_text" or "final_image".

That's it. The output is a single value (any type), so it plugs into whatever the stored thing actually was - image, latent, model, conditioning, a plain string. Because the type is unknown until execution, the bundled frontend JS watches what comes back and re-types the output port and retitles the node to something like DDM Get (my_latent), which is a nice touch for reading a big graph.

One honest caveat: the README advertises an optional default input that fires when the id isn't found. Look at the shipped code and it isn't there - info_schema lists only id, and execute just returns None for a missing key. If a tutorial tells you to wire up a default, it's describing a version that doesn't exist yet. Don't go hunting for the input.

Where people get burned

The code does two clever things and they cut both ways:

• IS_CHANGED returns float("nan"), which is never equal to itself, so ComfyUI always re-executes this node. That's necessary - otherwise the first None would get cached forever. But it also means the node runs on every pass even if nothing upstream changed.
• VALIDATE_INPUTS always returns True, so you never get a red validation error for a missing id. Convenient, but it means the workflow "works" and silently hands you None instead of telling you the Set node never ran.

The bigger trap is ordering. The README claims "ComfyUI handles this automatically," but Get has no data dependency on Set - there's no wire between them for the executor to respect. On the first run, Get typically executes before Set has stored anything, so you get None; run it again and the value appears. Same thing if you mute or bypass the Set node: the storage never gets filled, and Get quietly returns None (this is exactly the "get is not accessible if set is disabled" complaint people make about this class of node). And because the storage lives in server memory, it resets the moment you restart ComfyUI - these are per-session variables, not persistence. If you actually need a value to survive a restart or live across separate runs, you want something file-backed like WAS Node Suite's Save Cache / Load Cache, not this.

Installing it

Clone into custom_nodes and restart - that's the whole install, no models, no extra Python packages, nothing but a small stdlib script and one JS file:

cd ComfyUI/custom_nodes
git clone https://github.com/Revmagi/DDM_bundle

Then restart ComfyUI. Note the README's own clone URL is a placeholder (yourusername/DDM_Bundle.git) and it lists ComfyUI Manager support as "coming soon" - so don't count on finding it in Manager's search. Clone the real repo. Like any custom node, the code runs with full user-level access on import, so grab it from the actual repository, not a random paste.

Verdict: for a single-name recall node, it's fine - just remember it's a memory key, not a cache, and that the first run of any new workflow will probably hand you a None before the Set catches up.