00 Close Session
The polite way to end a ZMongo workflow
- session
- json
00 Close Session is the bookend to the 00 API Key Session node. It takes the session your key node created and tears it down cleanly, outputting a short JSON confirmation. That's the whole job - it's about as close as this pack gets to a "housekeeping" node.
Do you need it? Honestly, mostly no. ComfyUI sessions here are lightweight HTTP clients; the API session just closes its underlying requests session, which Python would clean up anyway when the graph finishes. For a one-off render you can skip it entirely and nothing breaks. Where it earns its keep is in long-running or looped setups - batch servers, queue-driven rigs, graphs that run for hours - where explicitly closing the connection after the last DB call keeps sockets from lingering and makes resource usage predictable.
How it works
One required input, session (ZMONGO_API_SESSION), straight from the API Key Session node. It calls the session object's close() and returns a single output:
json-{"success": true, "message": "Session closed."}on the happy path, or an error payload if the session wasNoneor the close failed.
Note there's no refresh output here, unlike most of the pack's write nodes. Nothing downstream needs to re-run after a close, and there's no data to invalidate - you're just hanging up the phone.
When it actually matters
Two scenarios make it worth the extra node on your canvas:
- Scheduled/batch workflows. If you're running the same graph repeatedly (say, a nightly pipeline that pulls images from a collection), closing the session at the end keeps each run's connection from piling up.
- Graphs that switch backends. If a workflow alternates between hosted API and Local File Store sessions, closing the hosted one explicitly avoids any ambiguity about which session is alive.
Install and gotchas
Install via ComfyUI Manager (search ComfyUI-ZMongo) or:
cd ComfyUI/custom_nodes
git clone https://github.com/CentralFloridaAttorney/ComfyUI-ZMongo
then restart. Like the whole pack, the real requirements.txt is heavy - this node itself needs nothing but requests, so don't be alarmed if Manager takes a while to pull the rest.
The one trap: it needs a real session output from the key node. Wire it to anything else - a string, a local store session - and you'll get a "No session provided" JSON instead of a clean close. And don't put it between the session node and your database nodes; closing the session doesn't invalidate the output, but a dead session flowing downstream can confuse debugging. Put it at the end of the chain.
Inputs (1)
| Name | Type | Default | Description |
|---|---|---|---|
| session | ZMONGO_API_SESSION | — |
Outputs (1)
| Name | Type | Description |
|---|---|---|
| json | STRING | — |