Expose session ttl / expire_time through the api_server REST layer and get_fast_api_app

[roanny]

Feature request

Problem

v2.4.0 added ttl / expire_time support to VertexAiSessionService.create_session(**kwargs) (commit 49d4441). However, deployments that serve ADK through get_fast_api_app / adk api_server (e.g. a Cloud Run service with a web frontend that manages sessions over the REST endpoints) have no way to set a session TTL at all:

1. The REST create-session endpoints do not accept it. POST /apps/{app_name}/users/{user_id}/sessions/{session_id} accepts only state, and POST /apps/{app_name}/users/{user_id}/sessions accepts only state / session_id / events (cli/api_server.py — create_session_with_id / create_session). Neither forwards ttl/expire_time kwargs to the session service.
2. The --auto_create_session path creates sessions implicitly on /run without any TTL either.
3. There is no service-level default to fall back on: the VertexAiSessionService constructor takes no TTL parameter, get_fast_api_app accepts only a session_service_uri string (so a pre-configured/subclassed service instance cannot be injected), and the agentengine:// URI has no TTL query parameter.

The net effect: REST-surface users cannot adopt the new TTL capability without monkey-patching private internals (the REST handler or the service factory).

Proposed solution

Any of the following (in order of preference — they are complementary):

1. Accept optional ttl / expire_time fields in the REST create-session request bodies and forward them as kwargs to session_service.create_session(...).
2. Support a default TTL at service construction — a VertexAiSessionService constructor kwarg, surfaced through a session_service_uri query parameter (e.g. agentengine://<id>?ttl=7200s) and/or a get_fast_api_app parameter. This would also cover the --auto_create_session path, which has no request body to extend.

Alternatives considered

• Subclassing VertexAiSessionService with a TTL default and registering it through the service registry (services.py in agents_dir + get_service_registry().register_session_service(...), which create_session_service_from_options consults first): works, but it is per-deployment custom code — a private-ish factory each deployment must maintain and re-verify on every ADK bump. First-class ttl support in the REST body and/or a construction-time default would serve every integration without that custom surface.
• Patching the REST handler: private API, breaks on every upgrade.
• Setting expiration out-of-band via the Agent Engine Sessions API after creation: races with --auto_create_session and doubles the API surface the client must manage.

Use case

Production agent on Cloud Run (get_fast_api_app + session_service_uri="agentengine://<id>"), with a browser frontend that creates/loads sessions exclusively through the ADK REST endpoints. We want cost/privacy hygiene: sessions that auto-expire after a retention window instead of accumulating indefinitely in Agent Engine.

Related

#4594 tracks the same gap on the AdkApp.async_create_session remote surface (Vertex AI SDK proxy path). This issue covers the api_server/get_fast_api_app REST surface — together they would make the v2.4.0 TTL capability reachable from every documented integration path.

Environment

• google-adk: 2.4.0
• Python: 3.12

[sanketpatil06]

Hi @roanny , Thanks for raising this. the request is currently being reviewed, and we will let you know if anything further is needed. Thank you for your understanding.

[ItsMacto]

Hi @roanny , I'd like to take this one. I recently contributed to the same REST layer (#6376) and want to take on a bigger contribution.

I'm planning to implement option 1 from your list as a first, focused PR, with option 2 (service-construction-time default via URI param, covering --auto_create_session) as a follow-up. Proposed shape:

• Add optional expire_time and ttl fields to CreateSessionRequest, mirroring the Vertex API (mutually exclusive; validation error if both are set).
• Forward them to session_service.create_session(...) only when set, so existing backends and callers are untouched.
• If either field is set but the configured session service doesn't support expiration kwargs (e.g. in-memory, database), return a 400 rather than silently ignoring it — a caller who requested expiration shouldn't get a session that never expires.
• The deprecated POST .../sessions/{session_id} endpoint stays as-is.
• Unit tests covering forwarding, the both-fields-set validation, and the unsupported-backend 400.

@sanketpatil06 happy to adjust the shape if the team prefers a different approach otherwise I'll have a PR up shortly.