09 ZMongo Content Pack Save

Once you've built a content pack with 09 ZMongo Content Pack Build, this is how it gets permanent. Save V3 takes the in-memory ZMONGO_CONTENT_PACK and writes it as a document into a database collection, keyed by name and project, so you can pull it back out later on any rig that shares the same backend.

That "shared backend" part is the point. ComfyUI-ZMongo runs in two modes: a hosted API you authenticate to, or a local file store when you supply no credentials. Either way, the session comes from the 00 API Key Session node (or 00 Local File Store Session), and it's the session input here. No session, no save.

What you set

• target_collection - where the pack lands. Defaults to text_agent_context_packs, which is the pack's standard content-pack collection; change it only if you know you're splitting things up.
• overwrite_mode - the behavior that matters most:
  • replace_by_name (default) - upserts: if a pack with the same name+project exists, it's replaced.
  • create_version - writes a new copy with a fresh version_id every run. Your history accumulates instead of being clobbered.
  • create_new - always inserts, never touches the old one.
  • replace_by_document_id - targets a specific existing document via the document_id input.

If you run a workflow twice with replace_by_name, the second run overwrites the first. If you want an audit trail of every parameter set you've tested, switch to create_version. That's the whole craft of this node - choosing your retention policy.

Outputs

pack_ref is a ZMONGO_CONTENT_PACK_REF - a small handle pointing at collection + document id that other ZMongo nodes can consume. document_id is the string version of that, and content_pack_json echoes back what was stored so you can sanity-check. success is your flag, and refresh is a dirty-token string that changes every run - wire it into downstream nodes that need to re-execute when the save happens.

Common issues

The biggest trap is forgetting which mode you're in. replace_by_name finds packs by content_pack_name + project_name; if you change the pack's name but expect the old document to be updated, you'll silently get a second document. And because the save goes through your session's backend, the usual auth failures apply - if a save reports success: false, check the session node first, then the collection name. This node is one of the few content-pack nodes that genuinely can't run offline; it always talks to storage.