Automatically create new session

[lwangverizon]

** Please make sure you read the contribution guide and file the issues in the right place. **
Contribution guide.

Is your feature request related to a problem? Please describe.
A clear and concise description of what the problem is. Ex. I'm always frustrated when [...]

Describe the solution you'd like
A clear and concise description of what you want to happen.

Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.

Additional context
Add any other context or screenshots about the feature request here.

[lwangverizon]

Feature Request: Auto-create Session in get_session Method

Is your feature request related to a problem? Please describe.

When building frontend applications with ADK, there's often a limitation where the frontend cannot always guarantee that create_session is called before initiating a conversation. This creates friction in the user experience because:

• Users may refresh the page or navigate directly to a conversation URL with a specific session_id
• Frontend state management may lose track of whether a session was already created
• Mobile apps or single-page applications may have complex lifecycle management where ensuring create_session is called first adds unnecessary complexity
• This forces developers to implement additional logic to check session existence before every conversation

Currently, if get_session is called with a non-existent session_id, it returns None, requiring the frontend to explicitly handle this case and call create_session separately.

Describe the solution you'd like

Modify the get_session method in DatabaseSessionService to automatically create a session if it doesn't exist in the database. This "get or create" pattern is common in many frameworks and provides a more developer-friendly API.

The implementation should:

1. Attempt to fetch the session from the database
2. If the session doesn't exist (returns None), automatically call create_session with the provided parameters
3. Retrieve and return the newly created session
4. Maintain backward compatibility - existing code continues to work without changes

This allows frontends to simply call get_session with a session_id and be confident that the session will be available, regardless of whether it was previously created.

Describe alternatives you've considered

1. Keep current behavior and require explicit create_session calls: This maintains strict separation but places burden on frontend developers to manage session lifecycle

2. Add a separate get_or_create_session method: This would preserve the original get_session behavior but adds API complexity and requires developers to know which method to use

3. Frontend-side session caching: The frontend could maintain its own cache of created sessions, but this adds complexity and potential synchronization issues

4. Add a flag parameter to get_session: A create_if_missing boolean parameter could control the behavior, but this adds API surface area and makes the common case more verbose

Additional context

This change implements the solution by modifying the get_session method in database_session_service.py (lines 286-296):

storage_session = await sql_session.get(
    schema.StorageSession, (app_name, user_id, session_id)
)
if storage_session is None:
    await self.create_session(
      app_name=app_name,
      user_id=user_id,
      session_id=session_id,
    )
    storage_session = await sql_session.get(
        schema.StorageSession, (app_name, user_id, session_id)
    )

[wyf7107]

Hi thank you for reporting this! In your front end application, you can detect whether your session id exist or not, and if its not, then you can call create_session and get a new id and use that id for communication. This is what we do in ADK Web that looks like creating a new session automatically

[adk-bot]

This issue has been automatically marked as stale because it has not had recent activity for 7 days after a maintainer requested clarification. It will be closed if no further activity occurs within 7 days.