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

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