Summary
With forward_session_id_as_context_id=True, RemoteA2aAgent forwards only ctx.session.id as the remote A2A context_id.
Because local ADK session identity also includes the user/application context, two distinct users that happen to use the same local session ID can be mapped to the same remote A2A context.
Root cause
Introduced by commit e10a1becd3ab44654a57e45b3b288b810c5b5602.
The forwarding logic uses the existing remote context ID or the raw local session ID, but does not include user_id or app_name in the derived value.
Reproduction
Two locally distinct sessions:
user-A / session s1
user-B / session s1
With forward_session_id_as_context_id=True, both outbound A2A requests use:
Against a remote implementation that keys conversation state from that context ID, both calls resolve to the same remote context.
In the reproduction:
- User A stores remote history containing
SECRET_FROM_USER_A
- User B then calls the same remote agent with its own local
session_id="s1"
- User B receives:
PRIOR_REMOTE_MESSAGE=SECRET_FROM_USER_A
Current HEAD tested at the time:
2e6ec4aad50ca4ebe60e9931f26f7ea7e466f17f
The existing upstream tests for the forwarding option still passed; they verify the raw session ID is forwarded, but do not cover two distinct users sharing the same session ID.
Expected behavior
Enabling local-to-remote session continuity should preserve local isolation. Distinct local users should not be collapsed into the same remote context solely because their session IDs are equal.
Actual behavior
The forwarded identifier drops the local user/application namespace and can therefore collide across otherwise distinct ADK sessions.
Suggested direction
Derive the forwarded context identifier from the full local session identity, or otherwise namespace it with the relevant user/application identity. A regression test with two different users and the same session ID would cover the collision case.
Summary
With
forward_session_id_as_context_id=True,RemoteA2aAgentforwards onlyctx.session.idas the remote A2Acontext_id.Because local ADK session identity also includes the user/application context, two distinct users that happen to use the same local session ID can be mapped to the same remote A2A context.
Root cause
Introduced by commit
e10a1becd3ab44654a57e45b3b288b810c5b5602.The forwarding logic uses the existing remote context ID or the raw local session ID, but does not include
user_idorapp_namein the derived value.Reproduction
Two locally distinct sessions:
With
forward_session_id_as_context_id=True, both outbound A2A requests use:Against a remote implementation that keys conversation state from that context ID, both calls resolve to the same remote context.
In the reproduction:
SECRET_FROM_USER_Asession_id="s1"PRIOR_REMOTE_MESSAGE=SECRET_FROM_USER_ACurrent HEAD tested at the time:
2e6ec4aad50ca4ebe60e9931f26f7ea7e466f17fThe existing upstream tests for the forwarding option still passed; they verify the raw session ID is forwarded, but do not cover two distinct users sharing the same session ID.
Expected behavior
Enabling local-to-remote session continuity should preserve local isolation. Distinct local users should not be collapsed into the same remote context solely because their session IDs are equal.
Actual behavior
The forwarded identifier drops the local user/application namespace and can therefore collide across otherwise distinct ADK sessions.
Suggested direction
Derive the forwarded context identifier from the full local session identity, or otherwise namespace it with the relevant user/application identity. A regression test with two different users and the same session ID would cover the collision case.