ComfyDeploy API Clear Cached Run IDs (Soze)

The reset button on this pack's run-id cache, built around ComfyDeploy - a separate hosted platform for running ComfyUI workflows as an API. Once you've queued a batch, pulled every ID back out with ComfyDeploy API Cached Run Info, and collected whatever results you needed, this empties the cache file so the next batch starts clean instead of accumulating run_ids from every batch you've ever queued into one growing pile.

How it works

Point it at cache_save_folder and it clears the cache file at that path. The schema gives it two outputs, run_id and status, but doesn't spell out exactly what run_id represents after a clear - most plausibly the last ID that was in the cache before the wipe, but that's an inference, not a documented fact. Verify it once with a text preview node before writing logic that depends on its exact value.

The inputs and outputs that matter

One required input: cache_save_folder (STRING) - has to match the path the other two cache nodes in this pack are using, or you'll clear a cache file that was never actually being read from.

Outputs: run_id 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. Local file operation only - no CD_API_KEY needed for this node specifically.

Common issues & troubleshooting

This is a destructive operation on the cache, so the real risk isn't a bug - it's wiring it somewhere that fires automatically on every run of a workflow you re-execute constantly. Do that and you'll clear run_ids you haven't actually retrieved and acted on yet. Keep this node deliberate: trigger it explicitly at the end of a batch pipeline, after Cached Run Info has already pulled what it needs, not as a standing part of every execution.

Same path-matching caveat as its two siblings in this pack: if clearing here doesn't seem to affect what Cached Run Info reads back afterward, compare cache_save_folder across all three nodes for an exact match - a mismatched path means you're managing two different cache files without realizing it.

If you're building this into an automated pipeline rather than clicking through it by hand, consider gating this node behind the same has_run_ids check that Cached Run Info exposes - clearing an already-empty cache is harmless, but making the clear conditional on "there was actually something there" gives you one more place to notice if a batch silently produced zero cached runs when you expected several.