Repository navigation
DatabaseSessionService.list_sessions lacks pagination support #4621
Description
Description
DatabaseSessionService.list_sessions() queries all session rows for a given app_name (and optional user_id) without any pagination mechanism (LIMIT/OFFSET or cursor-based). When the number of sessions under an app grows large, this causes severe performance issues.
Impact
In our production environment with ~10k sessions per app, calling list_sessions() takes approximately 74 seconds to return, making the API endpoint essentially unusable.
Current Behavior
# base_session_service.py
class ListSessionsResponse(BaseModel):
sessions: list[Session] = Field(default_factory=list)
async def list_sessions(
self, *, app_name: str, user_id: Optional[str] = None
) -> ListSessionsResponse:
...The method returns all sessions at once with no way to limit the result set.
Proposed Solution
Add pagination support to BaseSessionService.list_sessions() and DatabaseSessionService:
class ListSessionsResponse(BaseModel):
sessions: list[Session] = Field(default_factory=list)
next_page_token: str | None = None
async def list_sessions(
self,
*,
app_name: str,
user_id: str | None = None,
page_size: int = 20,
page_token: str | None = None,
) -> ListSessionsResponse:
...The implementation should:
- Accept
page_size(with a reasonable default, e.g. 20, max 100) andpage_token - Query with
LIMIT/OFFSET(or cursor-based pagination) - Order by
update_time DESCfor consistent results - Return
next_page_tokenwhen more results are available - Maintain backward compatibility (default behavior returns first page)
Workaround
We currently bypass DatabaseSessionService.list_sessions() by querying PostgreSQL directly with LIMIT/OFFSET in our service layer.
Environment
- ADK version: 1.25.1
- Python: 3.12
- Database: PostgreSQL with asyncpg
Activity
feat: add pagination support to DatabaseSessionService.list_sessions
klateefa commentedon Feb 27, 2026
@rusherman
Thank you for submitting this feature request. It’s currently under review by our team, and I’ll keep you posted on any updates. We appreciate your input!
xuanyang15 commentedon Feb 28, 2026
@DeanChensj Could you please take a look?
ecanlar commentedon Mar 6, 2026
I have the same problem.
ecanlar commentedon Mar 12, 2026
Hi team! We're currently planning our next deployment cycle and were wondering if this pagination fix is likely to be merged soon. The current workaround of querying the DB directly isn't ideal for our long-term architecture. Do you have a rough ETA or a target version for this update? Appreciate the support!
nightpool commentedon Apr 22, 2026
@DeanChensj @xuanyang15 any update here?
rialytics-software commentedon Jul 24, 2026
Hi what is the status here? This was done pretty fast in adk-js. Also, same pagination required for events as well?
jellevdberggg commentedon Sep 15, 2026
What is the status here? We're having a very slow sessions endpoint right now.
inamdarmihir commentedon Oct 29, 2026
Opened #7799 for this.
list_sessionsgets optionalpage_size/page_tokenand the response an optionalnext_page_token; with neither passed, behavior is unchanged. It is keyset paging on the existing(last_update_time, user_id, id)order, so pages stay correct if sessions change between calls (adk-js uses offset paging, which skips or repeats rows in that case). The database and sqlite services push the cursor andLIMITinto SQL; Vertex AI, Redis, MongoDB and Firestore accept the same arguments but still slice client-side. The sessions endpoint takes the same query parameters and returns the next token in anX-Next-Page-Tokenheader. It touches every backend because the base signature is shared, so I can split it if that's easier to review. I only ran the SQL path on sqlite.