Repository navigation
Title: DatabaseSessionService.append_event raises stale session error with LongRunningFunctionTool ADK Version #3717
Description
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.
Activity
pankajGT commentedon Dec 11, 2025
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 commentedon Jan 18, 2026
I'm observing the same issue after an async tool call (normal
FunctionTool, notLongRunningFunctionTool) that takes a few seconds:Can we reopen the issue? Is there any workaround that can be implemented in the meantime?
ADK version: 1.22.0
hungpq-ai commentedon Jan 18, 2026
ilbertt commentedon Jan 18, 2026
@hungpq-ai sorry I couldn't get what you mean here. Could you please clarify it? Thanks
GustafANexer commentedon May 6, 2026
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:
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 commentedon May 12, 2026
@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!
surajksharma07 commentedon May 25, 2026
@hungpq-ai The original floating-point false positive (equal timestamps flagged as stale) has been addressed in newer ADK versions — the current append_event uses exact _storage_update_marker integer comparison instead of the raw timestamp > check, and syncs last_update_time after each write to prevent float drift false positives.
@GustafANexer the requested_tool_confirmations flow failing in v1.28.1/v1.31.1 looks like a distinct sub-case where intermediate tool events advance the DB marker while the runner's session reference still holds the original marker.
Worth retesting in v2.1.0 before assuming it's still broken — and if it is, a fresh issue with a minimal repro against v2.1.0 would get it tracked cleanly.
Closing this since there's been no update for two weeks — feel free to reopen or file a new issue if the stale session error still shows up in the latest version!
hungpq-ai commentedon May 25, 2026