fix(sessions): stop a session id being forked across two users

[philmerrell]

Found while investigating prod session 5f34d2b0. Unrelated to the outage itself.

The bug

_get_session_by_gsi returns None both for "no such session" and for "exists, but owned by someone else". Callers can't tell those apart, so ensure_session_metadata_exists reads the second case as the first and creates a second metadata row on the same session id under the requester. Its attribute_not_exists(PK) guard can't catch this — the new row has a different PK (USER#{requester}), so the conditional put succeeds.

Session ids travel in shareable /s/{sessionId} URLs. Opening someone else's link 404s on the metadata read, but the SPA then treats the session as new and lets the user send. That send is what forked it.

What it is not

Not a confidentiality bug. Conversation content lives in AgentCore Memory keyed by actor id (get_messages_from_cloud passes actor_id=user_id), so the second user only ever saw an empty thread — never the owner's messages. Verified in the prod logs: Retrieved 0 memories from namespace: /strategies/.../actors/{second-user}/sessions/5f34d2b0....

What it actually broke

Beyond the duplicate row and the spend attached to it: both rows carry identical GSI_PK/GSI_SK, and DynamoDB returns them in an unspecified order. Every lookup read items[0], so after a fork the original owner's session could resolve to the other user's row, fail the ownership check, and look "not found" to every marker helper. That is why the prod logs show update_session_activity: session ... missing and could not be created against a session that plainly existed.

Changes

• session_owned_by_other_user makes the distinction explicit. Fail-open — it guards a rare misuse and must never take the chat path down. Returns True only when rows exist and none belong to the caller, so a legitimate owner is never blocked even where a fork is already attached.
• ensure_session_metadata_exists refuses to create over another owner (backstop for every pre-create path), and the invocations route rejects the turn with 404 — not 403, so the response says nothing about whether the session exists, matching what GET /sessions/{id}/metadata already returns.
• Both GSI lookups now scan every returned row for the caller's own instead of reading items[0]. Forked rows already exist in prod, so the read path has to stay deterministic over them. There were two copies of this ownership check; they're both fixed.

Testing

7 new tests (moto). Note the fork can no longer be created through the write path at all, so the determinism tests write the second row raw — that's what's already sitting in prod.

Full backend suite: 6908 passed, 6 skipped.

Not included

No backfill for the rows already forked in prod. Worth a separate pass once this is deployed — happy to write it.

🤖 Generated with Claude Code