fix(gemini): await sessionManager.ready before server starts accepting requests

[menny]

SessionManager loads all persisted Gemini sessions from ~/.gemini/sessions/*.json asynchronously in its constructor via this.ready = this.init(). Previously, sessionManager.ready was never awaited anywhere, so the server would start accepting WebSocket connections before loadSessions() had completed.

This created a race condition on the very first request after a server restart: if a client tried to resume an existing Gemini session, sessionManager.getSession(sessionId) would return undefined (the session hadn't been loaded from disk yet), causing the --resume <cliSessionId> flag to be silently omitted when spawning the Gemini CLI process. The CLI would then start a blank new session instead of continuing the prior conversation, with no error or indication to the user.

The fix adds await sessionManager.ready in startServer() immediately after await initializeDatabase(), following the same pattern already established for database initialization. This guarantees the session store is fully populated before any request handler can call getSession(), createSession(), or addMessage().

No other providers are affected: Claude, Cursor, and Codex session providers are stateless per-request (they read from disk or SQLite on demand) and have no equivalent eager-loading singleton.

Summary by CodeRabbit

• Bug Fixes

  • Enhanced server startup reliability by ensuring session data is fully loaded before the application begins accepting requests, preventing potential session-related errors and improving overall stability.

• Chores

  • Optimized server initialization sequence with improved asynchronous loading handling.

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: Repository UI

Review profile: CHILL

Plan: Pro

Run ID: ccef9c12-abea-4738-94bb-34079481c0c8

📥 Commits

Reviewing files that changed from the base of the PR and between f6200e3 and a46dbad.

📒 Files selected for processing (1)

• server/index.js

---

📝 Walkthrough

Walkthrough

The server initialization sequence now includes an additional asynchronous gate that waits for the session manager to be ready before proceeding, ensuring the Gemini session store is fully loaded prior to server startup.

Changes

Cohort / File(s)	Summary
Server Initialization server/index.js	Added await sessionManager.ready in the startup flow after database initialization but before web push configuration, introducing a new synchronization point to ensure the session store is loaded before the server accepts requests.

Poem

🐰 Hop, hop, hurray! A careful sequence takes the stage,
First the database wakes, then sessions turn the page,
Before the push and listen calls declare their start,
We wait for readiness—each component plays its part!

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title clearly and specifically describes the main change: awaiting sessionManager.ready before the server starts accepting requests to fix a race condition.
Docstring Coverage	✅ Passed	Docstring coverage is 100.00% which is sufficient. The required threshold is 80.00%.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[menny]

#691 surpass this