feat(memory): use event metadata for session/agent state identification#244
feat(memory): use event metadata for session/agent state identification#244
Conversation
Replace actorId prefix-based approach with event metadata for distinguishing session and agent state events. Add auto-migration for legacy events. Changes: - Add StateType enum (SESSION, AGENT) and metadata keys - Update create_session/create_agent to include stateType metadata - Update read_session/read_agent to filter by metadata - Add backwards-compatible auto-migration: legacy events are converted to new format on read (create new with metadata, delete old) - Add tests for legacy migration behavior
… filters - Fix pagination bug in list_events where API returns nextToken even with 0 results, causing "metadata filter mismatch" error on subsequent page - Add _retry_with_backoff method for handling eventual consistency when reading newly created agents via metadata filter - Track created agent IDs to handle updates during consistency window - Update test to account for retry behavior in legacy migration
| }, | ||
| ) | ||
| # Track created agent for eventual consistency handling | ||
| self._created_agent_ids.add(session_agent.agent_id) |
There was a problem hiding this comment.
This is to say that we support multiple agents per session ? Does Strands support that for session managers ? And also, this means we're using metadata to store and retrieve events from one agent_ID and not branches.
There was a problem hiding this comment.
_created_agent_ids is a fallback for when list_events_by_filter fails to find an agent due to eventual consistency. Newly created events aren't immediately visible when filtering by metadata - there's a short propagation delay. If the metadata query returns nothing but the agent_id is in _created_agent_ids, we know the agent was created and proceed accordingly rather than failing in update_agent
| ] | ||
|
|
||
| # Use retry with backoff to handle eventual consistency | ||
| events = self._retry_with_backoff( |
There was a problem hiding this comment.
Should we do retries for functions like read_agent ? It's causing unnecessary costs, maybe it's just a new agent that's empty.
There was a problem hiding this comment.
Retries are needed because newly created events aren't immediately visible when filtering by event_metadata. Without retries, we may miss agent state updates.
2 participants
Summary
session_{session_id},agent_{agent_id}) with event metadata for identifying session and agent state eventsFixes #220
Fixes #196
Changes
Event Metadata for State Identification
StateTypeenum (SESSION, AGENT) and metadata constants (STATE_TYPE_KEY,AGENT_ID_KEY)Backwards Compatibility
Bug Fixes
list_eventswhere API returns nextToken even with 0 results, causing metadata filter mismatch errors_retry_with_backoffto handle eventual consistency when reading newly created agentsTest plan
Future Work
The following improvements are planned for subsequent PRs: