docs: update session persistence docs for read-consistency fix#457
docs: update session persistence docs for read-consistency fix#457MervinPraison wants to merge 1 commit into
Conversation
…449) - Update Multi-Process Safety section in session-persistence.mdx to document fresh reads - Add read-consistency note in persistence-json.mdx about file lock acquisition on reads - Add tip in session-protocol.mdx about custom stores reading fresh from backing store - Include sequence diagram showing read consistency between two store instances This reflects the behavior changes from PraisonAI PR #1759 which fixed read-staleness in DefaultSessionStore by making reads always disk-consistent. 🤖 Generated with [Claude Code](https://claude.ai/code) Co-authored-by: Mervin Praison <MervinPraison@users.noreply.github.com>
Qodo reviews are paused for this user.Troubleshooting steps vary by plan Learn more → On a Teams plan? Using GitHub Enterprise Server, GitLab Self-Managed, or Bitbucket Data Center? |
|
Warning Review limit reached
More reviews will be available in 41 minutes and 30 seconds. Learn how PR review limits work. Your organization has run out of usage credits. Purchase more in the billing tab. ⌛ How to resolve this issue?After more reviews become available, a review can be triggered using the We recommend that you space out your commits to avoid hitting the rate limit. 🚦 How do rate limits work?CodeRabbit enforces hourly rate limits for each developer per organization. Our paid plans include higher PR review limits than trial, open-source, and free plans. In all cases, reviews become available again over time. During sustained high-volume PR review activity, CodeRabbit may temporarily slow when the next review becomes available. Please see our Fair Usage Limits Policy for further information. ℹ️ Review info⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (3)
✨ Finishing Touches🧪 Generate unit tests (beta)
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. Comment |
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
This pull request updates the documentation to clarify that the session store uses file locking for both reads and writes to prevent in-memory cache staleness across multiple processes. Feedback on the changes points out that a newly added tip in the session protocol documentation incorrectly mentions get_session as part of the SessionStoreProtocol, which could mislead developers implementing custom stores.
| </Tip> | ||
|
|
||
| <Tip> | ||
| If your custom store backs onto shared storage (Redis, Postgres, S3, another file system), make `get_chat_history` and `get_session` read from that backing store on every call rather than caching in process memory. `DefaultSessionStore` guarantees this; downstream code (e.g. `BotSessionManager._load_history`) relies on it. |
There was a problem hiding this comment.
The tip mentions get_session, but get_session is not part of the SessionStoreProtocol (which only requires add_message, get_chat_history, clear_session, delete_session, and session_exists). Furthermore, downstream code like BotSessionManager._load_history only calls get_chat_history and does not rely on get_session. Mentioning get_session here is misleading for developers implementing custom stores.
Suggested Change
Update the tip to only refer to get_chat_history:
If your custom store backs onto shared storage (Redis, Postgres, S3, another file system), make `get_chat_history` read from that backing store on every call rather than caching in process memory. `DefaultSessionStore` guarantees this; downstream code (e.g. `BotSessionManager._load_history`) relies on it.
Summary
Updates session persistence documentation to reflect the read-consistency fixes from PraisonAI PR #1759.
Changes Made:
Background
PraisonAI PR #1759 fixed a read-staleness bug in DefaultSessionStore where reads could return stale cached data when multiple store instances shared the same session_dir. The fix makes all read operations (
get_chat_history,get_session,get_sessions_by_agent) reload from disk under FileLock on every call.This ensures that multiple processes sharing a session directory always see each other's latest writes, eliminating the stale-cache window that could cause LLMs to receive truncated chat context.
Fixes #449
🤖 Generated with Claude Code