Title: DatabaseSessionService.append_event raises stale session error with LongRunningFunctionTool ADK Version

[hungpq-ai]

ADK 1.17
When using LongRunningFunctionTool with DatabaseSessionService, the append_event method raises a ValueError about stale session even when timestamps are equal (not earlier). Error:
ValueError: The last_update_time provided in the session object '2025-11-26 04:50:50' is earlier than the update_time in the storage_session '2025-11-26 04:50:50'. Please check if it is a stale session.
Stack trace:
File "google/adk/cli/adk_web_server.py", line 1418, in event_generator
File "google/adk/runners.py", line 655, in _exec_with_plugin
await self.session_service.append_event(
File "google/adk/sessions/database_session_service.py", line 649, in append_event
raise ValueError(...)
Root cause: In database_session_service.py:648, the comparison uses >:
if storage_session.update_timestamp_tz > session.last_update_time:
raise ValueError("stale session...")
But the error message says "earlier than" when timestamps are actually equal. This happens due to floating-point precision issues when multiple events are yielded in quick succession. Steps to reproduce:
Use DatabaseSessionService
Create agent with LongRunningFunctionTool
User triggers the tool (e.g., checkout popup)
Frontend sends functionResponse back
Error occurs when ADK tries to append the response event
Expected behavior: Equal timestamps should not raise stale session error. Suggested fix: Add small tolerance for timestamp comparison or use >= with microsecond precision check.

[pankajGT]

Same Issue

ValueError: The last_update_time provided in the session object '2025-12-11 13:43:04' is earlier than the update_time in the storage_session '2025-12-11 13:43:24'. Please check if it is a stale session

[ilbertt]

I'm observing the same issue after an async tool call (normal FunctionTool, not LongRunningFunctionTool) that takes a few seconds:

ValueError: The last_update_time provided in the session object '2026-01-17 18:38:09' is earlier than the update_time in the storage_session '2026-01-17 18:44:54'. Please check if it is a stale session.

Can we reopen the issue? Is there any workaround that can be implemented in the meantime?

ADK version: 1.22.0

[hungpq-ai]

i was fix variable by change enum for LLM to detect easier so you can fix that error Vào CN, 18 thg 1, 2026 lúc 22:56 Luca Bertelli ***@***.***> đã viết:

…

*ilbertt* left a comment (google/adk-python#3717) <#3717 (comment)> I'm observing the same issue after an async tool call (normal FunctionTool, not LongRunningFunctionTool) that takes a few seconds: ValueError: The last_update_time provided in the session object '2026-01-17 18:38:09' is earlier than the update_time in the storage_session '2026-01-17 18:44:54'. Please check if it is a stale session. Can we reopen the issue? Is there any workaround that can be implemented in the meantime? — Reply to this email directly, view it on GitHub <#3717 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/BYVQQU3A7KHSRTZZBZELN5D4HOULJAVCNFSM6AAAAACNG6XQWSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTONRVGQZTINBSGU> . You are receiving this because you modified the open/close state.Message ID: ***@***.***>

[ilbertt]

i was fix variable by change enum for LLM to detect easier so you can fix
that error

Vào CN, 18 thg 1, 2026 lúc 22:56 Luca Bertelli @.***>
đã viết:
…

@hungpq-ai sorry I couldn't get what you mean here. Could you please clarify it? Thanks

[hungpq-ai]

I've modified the functions where variables are defined and listed under enum lists to forms that are easier for LLM to recognize and process, otherwise they would be flagged by LRF. Vào CN, 18 thg 1, 2026 lúc 23:03 Luca Bertelli ***@***.***> đã viết:

…

*ilbertt* left a comment (google/adk-python#3717) <#3717 (comment)> i was fix variable by change enum for LLM to detect easier so you can fix that error Vào CN, 18 thg 1, 2026 lúc 22:56 Luca Bertelli *@*.***> đã viết: … <#m_1630627118062042311_> @hungpq-ai <https://github.com/hungpq-ai> sorry I couldn't get what you mean here. Could you please clarify it? Thanks — Reply to this email directly, view it on GitHub <#3717 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/BYVQQUYKBJ6G62HEMMQX4Q34HOVGXAVCNFSM6AAAAACNG6XQWSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTONRVGQ2DCMZWGI> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[GustafANexer]

I experience the same issue with requested_tool_confirmations with version 1.28.1 and 1.31.1. When using 1.25.1 the flow works. Using PostgreSQL.
The tool resumes when the function response is sent, after_tool_callback and other tool calls work, but when model returns a response the application crashes with the error:

.venv\Lib\site-packages\google\adk\sessions\database_session_service.py", line 700, in append_event
    raise ValueError(_STALE_SESSION_ERROR_MESSAGE)
ValueError: The session has been modified in storage since it was loaded. Please reload the session before appending more events.

The tool calling events are created, but the actual model response event isn't created in the database. We don't reach after_agent_callback.

[surajksharma07]

@hungpq-ai From v1.26 onward the marker-based stale check is strict, so when intermediate events advance the DB marker while the original session reference is still held (as happens with LongRunningFunctionTool or any slow async tool), the append on that stale reference fails immediately instead of resyncing.

A workaround worth trying: wrap append_event to catch the "modified in storage" error, reload a fresh session snapshot from DB, copy _storage_update_marker and last_update_time back onto the stale session object, then retry the append.
That effectively restores the auto-reload behaviour that worked in v1.25.1.

Could you give this a try in your environment and confirm it stops the crash across your different tool flows?

Please test it thoroughly first, and once you're confident it holds up end-to-end, that would be a solid basis for raising a PR against database_session_service.py!