What happened?
When using DatabaseSessionService with MySQL, the very first append_event() after create_session() fails with:
ValueError: The session has been modified in storage since it was loaded.
Please reload the session before appending more events.
Steps to reproduce
- Create a
DatabaseSessionService connected to MySQL
- Call
create_session()
- Immediately call
append_event() on the returned session
Root cause
create_session() creates a timezone-aware datetime (tz=timezone.utc) and derives the _storage_update_marker from it (includes +00:00). But MySQL DATETIME(fsp=6) doesn't store timezone info — it silently drops it. When append_event() reads update_time back from MySQL, it gets a naive datetime (no +00:00), produces a different marker string, and the strict string comparison fails.
The code already handles this for SQLite and PostgreSQL by stripping tzinfo before writing (line 464 in database_session_service.py), but MySQL is not included in the check:
if is_sqlite or is_postgresql: # MySQL not included
now = now.replace(tzinfo=None)
Per MySQL docs: "MySQL converts TIMESTAMP values from the current time zone to UTC for storage, and back from UTC to the current time zone for retrieval. (This does not occur for other types such as DATETIME.)"
Expected behavior
append_event() should work immediately after create_session() without needing a re-fetch workaround.
Environment
- google-adk 1.28.0
- MySQL 8.0 with aiomysql
PreciseTimestamp → DATETIME(fsp=6)
What happened?
When using
DatabaseSessionServicewith MySQL, the very firstappend_event()aftercreate_session()fails with:Steps to reproduce
DatabaseSessionServiceconnected to MySQLcreate_session()append_event()on the returned sessionRoot cause
create_session()creates a timezone-aware datetime (tz=timezone.utc) and derives the_storage_update_markerfrom it (includes+00:00). But MySQLDATETIME(fsp=6)doesn't store timezone info — it silently drops it. Whenappend_event()readsupdate_timeback from MySQL, it gets a naive datetime (no+00:00), produces a different marker string, and the strict string comparison fails.The code already handles this for SQLite and PostgreSQL by stripping
tzinfobefore writing (line 464 indatabase_session_service.py), but MySQL is not included in the check:Per MySQL docs: "MySQL converts TIMESTAMP values from the current time zone to UTC for storage, and back from UTC to the current time zone for retrieval. (This does not occur for other types such as DATETIME.)"
Expected behavior
append_event()should work immediately aftercreate_session()without needing a re-fetch workaround.Environment
PreciseTimestamp→DATETIME(fsp=6)