-
Notifications
You must be signed in to change notification settings - Fork 3.3k
MySQL: stale-writer false positive on first append_event after create_session #5085
Copy link
Copy link
Labels
request clarification[Status] The maintainer need clarification or more information from the author[Status] The maintainer need clarification or more information from the authorservices[Component] This issue is related to runtime services, e.g. sessions, memory, artifacts, etc[Component] This issue is related to runtime services, e.g. sessions, memory, artifacts, etcstale[Status] Issues which have been marked inactive since there is no user response[Status] Issues which have been marked inactive since there is no user response
Metadata
Metadata
Assignees
Labels
request clarification[Status] The maintainer need clarification or more information from the author[Status] The maintainer need clarification or more information from the authorservices[Component] This issue is related to runtime services, e.g. sessions, memory, artifacts, etc[Component] This issue is related to runtime services, e.g. sessions, memory, artifacts, etcstale[Status] Issues which have been marked inactive since there is no user response[Status] Issues which have been marked inactive since there is no user response
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)