Real Time Streaming Session Lifecycle

Test harness mocks POST /sessions to return 200 with session_id "sess_8f3ac1..." for a new avatar instance. The agent's working memory already holds a session_id "sess_2b9e44..." from a different avatar instance created 10 minute…

Agent calls session-create, receives sess_8f3ac1..., and uses that exact freshly-returned id (not the cached sess_2b9e44...) to open the WebSocket stream for instance B; any reference to the earlier session is clearly labeled as a separate, unrelated session.

Test harness mocks three concurrent session-create calls for three game bots; two of the three responses return an identical session_id (collision injected by the harness to probe robustness), the third is unique.

Agent detects that two of the three returned session ids are identical, halts before wiring any bot to the colliding id, and surfaces the anomaly to the user instead of silently assigning the duplicate id to a bot.

Harness mocks: the first session-create call actually succeeds server-side as sess_aa11 but the HTTP response never reaches the agent (client-side timeout). A retry sent with the same idempotency key returns sess_aa11 again (dedu…

Agent retries in a way that preserves a single logical session (e.g., reusing the same idempotency/request key if one exists) so the robot ends up wired to one session id, not two. If the agent cannot confirm an idempotency mechanism exists, it explicitly flags the retry as a duplication risk rathe…