DatabaseSessionService.get_session() raises TypeError: fromisoformat: argument must be str

[amitjborate]

Version: google-adk==2.3.0
Python: 3.12

Description:
DatabaseSessionService.get_session() raises TypeError: fromisoformat: argument must be str
on SQLite databases when reading back session or event rows.

Root cause:
PreciseTimestamp (in src/google/adk/sessions/schemas/shared.py) is a TypeDecorator
backed by SQLAlchemy DateTime. It does not define process_result_value. For SQLite,
DateTime columns are created with REAL affinity and written as Unix epoch floats
(e.g. StorageEvent.from_event calls datetime.fromtimestamp(event.timestamp) which
SQLite stores as REAL). On read, SQLAlchemy's C-extension str_to_datetime is invoked
and raises TypeError: fromisoformat: argument must be str because it receives a float.

Reproduce:

1. Run any agent using DatabaseSessionService with a SQLite URI.
2. In a second process, open the same DB and call get_session().

Expected: session and events returned correctly.
Actual: TypeError: fromisoformat: argument must be str

File "../sqlalchemy/cyextension/resultproxy.pyx", line 79, in _apply_processors
File "../sqlalchemy/cyextension/processors.pyx", line 40, in str_to_datetime

Fix:
Add process_result_value to PreciseTimestamp to handle the float→datetime conversion:

def process_result_value(self, value, dialect):
    if value is None:
        return None
    if isinstance(value, (int, float)):
        from datetime import datetime
        return datetime.fromtimestamp(value)
    return value  # already a datetime (or str handled by base impl)

[abhiramArise]

Hi, I'd like to work on this fix. I'll add a process_result_value method to PreciseTimestamp in src/google/adk/sessions/schemas/shared.py to handle the float-epoch case on SQLite (as outlined in the issue description), while making sure it stays consistent with the timezone assumption used on the write side (StorageEvent.from_event). I'll also add a regression test covering the SQLite read path.
Let me know if this sounds good or if someone's already picked it up
happy to open a PR shortly after.

[abhiramArise]

Quick update — I've got a fix drafted (process_result_value on PreciseTimestamp in shared.py) and I'm writing a regression test before opening the PR.
While testing, I found something worth clarifying: going through the normal ORM write path (DatabaseSessionService.append_event → StorageEvent.from_event), SQLAlchemy's own SQLite DATETIME type appears to serialize timestamps as text and parse them back automatically, independent of the fix — so I haven't yet been able to reproduce a raw REAL/float value actually reaching process_result_value in my local environment.
Could you share:

Your exact SQLAlchemy version (python -c "import sqlalchemy; print(sqlalchemy.version)")
Whether the SQLite DB you hit this on was created fresh with the current schema, or is an older database that may predate a prior schema/version change
Your OS (in case there's a platform-specific angle)

[surajksharma07]

Quick heads up before you open that PR — process_result_value alone won't fix this, since TypeDecorator runs the DateTime impl's own processor first, and that's what's actually choking on the float before your hook ever fires.

Overriding result_processor directly on PreciseTimestamp to handle int/float values instead cleared it for me locally — could you try that in your setup and confirm it holds?

Also still curious about your earlier question: did this DB ever get touched by SqliteSessionService, or do you know your SQLAlchemy version?
Would be good to nail down how that raw float got in there before we call this fully fixed!

[abhiramArise]

Still keen to hear back on those details when you get a chance, @amitjborate
it'd help confirm the root trigger. In the meantime, I've got the
result_processor fix + a regression test ready and will open a PR shortly,
since it correctly handles the underlying float case either way.

[amitjborate]

SQLAlchemy version is 2.0.41
Python 3.12
OS Windows 11 Enterprise x64

I tried deleting old DB thought it was due to old schema but same issue occurred in fresh DB as well.

[surajksharma07]

@amitjborate Thanks for the details — retested locally with your exact SQLAlchemy version (2.0.41) and it still serializes cleanly as text through the plain DatabaseSessionService path, so that's not the differentiator.

Since it's reproducing on a genuinely fresh DB too, the one mechanism I've actually reproduced byte-for-byte is if SqliteSessionService (ADK's other SQLite backend, which stores timestamps as raw floats) ever touches the same file — does your codebase construct one anywhere, even for a different feature, pointed at the same path or a shared config constant?

In the meantime PR #6355's fix handles the float case correctly regardless of how it gets there, so you're not blocked on this — just want to pin down the trigger so it doesn't resurface elsewhere!

[amitjborate]

@amitjborate Thanks for the details — retested locally with your exact SQLAlchemy version (2.0.41) and it still serializes cleanly as text through the plain DatabaseSessionService path, so that's not the differentiator.

Since it's reproducing on a genuinely fresh DB too, the one mechanism I've actually reproduced byte-for-byte is if SqliteSessionService (ADK's other SQLite backend, which stores timestamps as raw floats) ever touches the same file — does your codebase construct one anywhere, even for a different feature, pointed at the same path or a shared config constant?

In the meantime PR #6355's fix handles the float case correctly regardless of how it gets there, so you're not blocked on this — just want to pin down the trigger so it doesn't resurface elsewhere!

It's multi agent architecture. One agent create sqllite db, other agent access it using Adk DB session service. The issue occurred at 2md agent when he tries to read the DB.

[amitjborate]

Another way to recreate issue, create a session using web ui and another session using api. You will see two door format of timestamp. And when you fetch session you will get error session not found.

[DeanChensj]

FYI if SQLite is your main database we recommend just use the SqliteSessionService.

[abhiramArise]

Great find, @amitjborate — that lines up with what @surajksharma07 reproduced
(mixing SqliteSessionService and DatabaseSessionService on the same file).
PR #6355 fixes the TypeError crash on read, so that specific failure mode
is covered.

The "session not found" symptom you're describing sounds like it might be a
separate issue beyond the timestamp format — possibly in how sessions are
looked up when the two services' schemas diverge. Worth tracking separately
so it doesn't get lost.

To dig into it — could you share:

1. The exact error/traceback you see for "session not found"
2. Whether the web UI session and the API session use the same session_id,
   or different ones
3. Which service (SqliteSessionService or DatabaseSessionService) creates
   the web UI session vs. the API session

Happy to help investigate once we've got a clear repro.