[Enhancement] MongoDB runtime store startup is slow due to full collection scan

Summary

When using Parlant 3.3.2 with MongoDB-backed runtime stores, server startup becomes very slow as the sessions and especially events collections grow.

The slow path appears to be SessionDocumentStore.__aenter__() opening the sessions and events collections. Internally, MongoDocumentDatabase.get_collection() runs find({}).to_list() over the entire collection every time the store is opened, then calls the document loader for every document.

Even when all documents are already at the target version, DocumentMigrationHelper.migrate() returns the document unchanged, and MongoDocumentDatabase.get_collection() still calls replace_one(doc, loaded_doc).

Observed behavior

Startup timing logs from our deployment:

• runtime.stores.mongodb: ~46.8s
• runtime.stores.mongodb.session_store: ~46.7s
• Mongo client creation itself: ~67ms

So the bottleneck is not the Mongo connection but opening the session store.

Expected behavior

If the store metadata version already matches the runtime store version, startup should not need to scan and rewrite every document in large collections.

Possible alternatives:

• Only scan documents whose version != target_version.
• Avoid replace_one() when the migrated document is identical to the original document.
• Persist a collection-level migration checkpoint/schema version so subsequent startups can skip full validation.
• Move expensive migration/validation into an explicit maintenance command instead of doing it on every runtime startup.

Relevant code

In Parlant 3.3.2:

• parlant.core.sessions.SessionDocumentStore.__aenter__()
  • opens sessions and events through get_or_create_collection()
• parlant.adapters.db.mongo_db.MongoDocumentDatabase.get_collection()
  • calls result_collection.find({}).to_list()
  • calls document_loader(doc) for every document
  • calls replace_one(doc, loaded_doc) if the loader returns a document
• parlant.core.persistence.document_database_helper.DocumentMigrationHelper.migrate()
  • returns the document when it is already at the target version

Impact

For production deployments with accumulated historical session/event data, every server restart pays an O(N) full collection scan cost, and may also perform unnecessary writes for already-current documents.