ComfyDeploy API Cached Run Info (Soze)

The read side of the run-id cache this pack builds around ComfyDeploy - a separate hosted platform for running ComfyUI workflows as an API. If you've been appending run_ids with ComfyDeploy API Cache Run IDs as you queue a batch of jobs, this is how you get them back: point it at the same cache_save_folder and it hands you everything that's accumulated there.

How it works

cache_save_folder in, and out comes the state of that cache: the accumulated run_ids, how many are cached (count), and a plain has_run_ids boolean so you can gate whatever comes next on whether there's actually anything to work with - no point trying to poll ComfyDeploy for results if nothing's been queued yet.

The intended shape of a workflow using all three of this pack's ComfyDeploy cache nodes: fire off N runs across N separate queue executions, appending each run_id as it comes back with the Cache node; then, on a separate pass (or once the whole batch is done), call this node once to pull the full list and go check ComfyDeploy for status or download the results.

The inputs and outputs that matter

One required input: cache_save_folder (STRING) - must match the path you've been writing to.

Outputs: run_ids, count (INT), has_run_ids (BOOLEAN), and status.

How to install it

ComfyUI Manager → search "ComfyUI_Soze" → install → restart. Manual:

cd ComfyUI/custom_nodes
git clone https://github.com/SozeInc/ComfyUI_Soze.git
pip install -r ComfyUI_Soze/requirements.txt

then restart. This node reads a local file, no network call - it doesn't need CD_API_KEY itself; that's for the parts of your setup actually calling ComfyDeploy.

Common issues & troubleshooting

has_run_ids is the guard worth actually using - wire it into a switch so you're not trying to parse run_ids as though it has content the very first time you run this before anything's ever been cached.

If this comes back empty and you're confident you cached something, the near-certain cause is a path mismatch: cache_save_folder here doesn't exactly match what Cache Run IDs wrote to. Compare the two strings character for character rather than assuming one of the nodes is broken - trailing slashes and small typos are the usual culprit.

Because run_ids comes back as a single output rather than a native ComfyUI list type, plan for how you're going to split it before you need to loop over individual IDs downstream - the schema doesn't document a delimiter, so print it once to a text preview and check the actual format (newline-separated, comma-separated, or something else) before wiring a splitter node around an assumption.