Summary
use_thread_id_as_session_id=True gives SessionManager.get_or_create_session an O(1) direct-lookup path — but SessionManager._find_session_by_thread_id has no flag branch: it always runs the O(n) list_sessions scan over all the user's sessions, matching _ag_ui_thread_id in each session's state.
ADKAgent.run calls _find_session_by_thread_id once per (thread, user) per process to hydrate the multi-instance session cache, so the scan still fires for every fresh chat and every cold thread — even with the flag on.
Measured impact (ag-ui-adk 0.6.5 + VertexAiSessionService, Cloud Run)
Each list_sessions scan against Vertex AI Agent Engine costs ~0.4–0.9s (API processing time), paid inside the user's turn before the first model call. With the flag-aware direct lookup below, our request→run-start segment dropped from ~1.1s to ~0.28s.
Suggested fix
The lookup should honor the flag (this is what we ship as a local monkey-patch today):
async def _find_session_by_thread_id(self, app_name, user_id, thread_id):
if self._use_thread_id_as_session_id:
return await self.get_session(thread_id, app_name, user_id)
# ... existing list_sessions scan for the legacy id-mapping mode ...With the flag on, the thread id IS the session id, so a direct get_session (None when absent) is both correct and O(1); the scan remains the right recovery path only for the legacy mode where the backend generates session ids.
Summary
use_thread_id_as_session_id=TruegivesSessionManager.get_or_create_sessionan O(1) direct-lookup path — butSessionManager._find_session_by_thread_idhas no flag branch: it always runs the O(n)list_sessionsscan over all the user's sessions, matching_ag_ui_thread_idin each session's state.ADKAgent.runcalls_find_session_by_thread_idonce per(thread, user)per process to hydrate the multi-instance session cache, so the scan still fires for every fresh chat and every cold thread — even with the flag on.Measured impact (ag-ui-adk 0.6.5 +
VertexAiSessionService, Cloud Run)Each
list_sessionsscan against Vertex AI Agent Engine costs ~0.4–0.9s (API processing time), paid inside the user's turn before the first model call. With the flag-aware direct lookup below, our request→run-start segment dropped from ~1.1s to ~0.28s.Suggested fix
The lookup should honor the flag (this is what we ship as a local monkey-patch today):
With the flag on, the thread id IS the session id, so a direct
get_session(None when absent) is both correct and O(1); the scan remains the right recovery path only for the legacy mode where the backend generates session ids.