feat: ✨ redis session class #789
Conversation
|
Thanks for the contribution! What's the benefit of redis in-memory session vs the current implementation? |
In my job, we develop conversational bots and are now implementing agents. For text-based interactions, we use Google Cloud Run to deploy our backend due to the asynchronous nature of conversations and the stateless nature of Cloud Run. However, with our current implementation, we noticed it can lead to a loop where session context is lost. By using Redis, we’re able to share session context across any number of instances, maintaining continuity and coherence throughout the conversation flow. |
| return {} | ||
| return json.loads(raw.decode()) | ||
|
|
||
| def _save_sessions( |
There was a problem hiding this comment.
Here is my 2cents:
Potential Race Condition on Session Saving
Lines 179–183 (_save_sessions) and usage in 69, 123, 147:
The _save_sessions method overwrites the entire set of sessions for a user+app key in Redis. If multiple requests attempt to create or update sessions for the same user/app at the same time, this can result in lost data due to concurrent updates overwriting each other.
Suggestion: Consider using Redis transactions, locks, or more granular session storage to avoid this risk.
Thanks for the contribution. I don't particularly understand this part: "By using Redis, we’re able to share session context across any number of instances, maintaining continuity and coherence throughout the conversation flow." Why does a shared memory can avoid the problems you mentioned. Could you help elaborate? |
Sure By integrating Redis, we can persist session data and share it across all instances. This allows us to maintain the current session state for each user. Additionally, we can use TTL (Time To Live) to automatically remove expired session data and keep the system clean. This solution helps in the case of Artificial Nerds to scale agent bots and avoid looped conversations caused by missed context. |
|
Any update on the status of this PR? |
|
Hi, we are preparing a new repo to house community contributions which will give more freedom to the community to add new features that extend ADK's features. Please stay tuned. |
Hi Bo! Are there any timeline available for that? We would love to add Redis session storage in our services. |
This pull request introduces a Redis-backed session service implementation, along with various enhancements and adjustments to improve consistency, functionality, and maintainability across the codebase. The most significant changes include the addition of the
RedisMemorySessionService, updates to theEventandSessionclasses to support serialization and deserialization, and the inclusion of Redis as a dependency.New Redis-backed session service:
RedisMemorySessionServiceclass to provide a Redis-backed implementation of session management. This includes methods for creating, retrieving, listing, and deleting sessions, as well as managing session state and events. (src/google/adk/sessions/redis_memory_session_service.py)__init__.pyin thesessionsmodule to includeRedisMemorySessionServicein the exports. (src/google/adk/sessions/__init__.py)Serialization and deserialization enhancements:
to_dictandfrom_dictmethods to theEventclass to enable serialization and deserialization of event objects. (src/google/adk/events/event.py)to_dictandfrom_dictmethods to theSessionclass for similar functionality, enabling seamless handling of session data in the Redis service. (src/google/adk/sessions/session.py)Dependency updates:
redis>=6.0.0as a new dependency inpyproject.tomlto support the Redis-based session service. (pyproject.toml)Consistency improvements:
EventandSessionclasses to use double quotes for consistency. (src/google/adk/events/event.py) [1] [2] (src/google/adk/sessions/session.py) [3]