Skip to content

Firestore session and memory services: fix nested state merge, package exports and memory duplicates聽#7192

Description

@vishal-bulbule

馃敶 Required Information

Is your feature request related to a specific problem?

Yes. Python has shipped FirestoreSessionService and FirestoreMemoryService since v1.31.0
(#5088), but they don't behave like the other session and memory services, and there is no
Python documentation for them. Testing them against a real Firestore database on 2.9.1 and
main (f33d4923), I reproduced these problems:

  1. Nested user: / app: state is merged instead of replaced. Updating user:profile
    from {"name": "Alice", "role": "admin"} to {"name": "Alice"} stores
    {"name": "Alice", "role": "admin"}, so the removed key comes back on the next
    get_session. The in-memory, SQLite and database session services replace the value.
    Cause: user_states / app_states are written with transaction.set(..., merge=True) in
    both create_session and append_event, and Firestore deep-merges nested maps.
    Session-scoped state is not affected (it is stored as JSON).
  2. The services can't be imported from their package.
    from google.adk.integrations.firestore import FirestoreSessionService raises ImportError
    because integrations/firestore/__init__.py exports nothing. It is the only package under
    integrations/ like this.
  3. GetSessionConfig(after_timestamp=...) returns the wrong events. Events are stored with
    "timestamp": firestore.SERVER_TIMESTAMP, so the filter and event ordering use the write
    time instead of event.timestamp.
  4. get_user_state is not supported. It raises NotImplementedError, while the in-memory,
    database, SQLite and Redis session services implement it.
  5. add_session_to_memory stores duplicates. Each call writes a new document per event, so
    adding the same session again (for example after every turn) stores every memory again.
    Search hides this by de-duplicating results, but storage keeps growing.
    add_events_to_memory is also not implemented; InMemoryMemoryService supports it.
  6. Positional-filter warnings. list_sessions and get_session with after_timestamp
    call .where("field", op, value), so google-cloud-firestore emits
    UserWarning: Detected filter using positional arguments on every call.

Describe the Solution You'd Like

Make the Firestore services behave like the other backends, with no change to their public
API other than implementing two existing base-class methods:

  1. Write user: / app: state back whole so a new value replaces the old one.
  2. Export FirestoreSessionService and FirestoreMemoryService from
    google.adk.integrations.firestore, loaded lazily (as integrations/model_armor does) so
    importing the package still does not require google-cloud-firestore.
  3. Store each event's own timestamp so after_timestamp and event ordering use event time.
  4. Implement get_user_state by reading the user_states document the service already writes.
  5. Give each memory entry a stable document ID derived from app, user, session and event IDs,
    so re-adding a session overwrites instead of duplicating, and implement
    add_events_to_memory.
  6. Pass query filters as where(filter=FieldFilter(...)), as FirestoreMemoryService already
    does.

Impact on your work

I build agents for Google Cloud customers, and Firestore is the natural serverless session
store for agents on Cloud Run. Today:

  • A value removed from nested user or app state (for example a role or a permission flag)
    silently stays in Firestore and comes back on the next turn.
  • Memory storage grows with every turn when sessions are added to memory after each turn.
  • Moving an agent between session services changes its behavior.
  • Python users have no documentation showing how to use these services: the adk.dev
    Firestore page covers Java only.

Willingness to contribute

Yes. I have the fix ready with unit tests, one commit per item above, and can open the PR
once this is triaged. I will also open a PR in google/adk-docs adding Python usage to the
Firestore page.


馃煛 Recommended Information

Describe Alternatives You've Considered

  • DatabaseSessionService with Cloud SQL or AlloyDB: works correctly, but needs a database
    instance to run and manage, which Firestore avoids.
  • VertexAiSessionService: works, but ties sessions to Agent Engine.
  • Workarounds on the current Firestore services: import from the full module path, avoid dict
    values in user: / app: state, and add each session to memory only once. These avoid the
    symptoms but are easy to miss, and nothing in the docs mentions them.

Proposed API / Implementation

No new public API. The changes stay inside src/google/adk/integrations/firestore/ and its
unit tests:

# 1. create_session / append_event: write the full, already-updated dict
transaction.set(user_ref, current_user)  # was: transaction.set(user_ref, current_user, merge=True)

# 3. append_event: store the event's own time
"timestamp": datetime.fromtimestamp(event.timestamp, tz=timezone.utc)  # was: firestore.SERVER_TIMESTAMP

# 5. memory: stable document ID per event
doc_id = sha256("\x00".join((app_name, user_id, session_id or "", event.id)))

After the change, a local run of the shared session contract suite
(tests/unittests/sessions/test_session_service.py) against a real Firestore database goes
from 18 passed / 13 failed to 27 passed / 4 failed. The 4 remaining failures are covered below.

Additional Context

Minimal reproduction for item 1 (pip install google-adk==2.9.1 google-cloud-firestore, a
Firestore Native database):

import asyncio, time
from google.adk.events.event import Event
from google.adk.events.event_actions import EventActions
from google.adk.integrations.firestore.firestore_session_service import FirestoreSessionService
from google.cloud import firestore

async def main():
  client = firestore.AsyncClient(project="PROJECT", database="DATABASE")
  svc = FirestoreSessionService(client=client)
  s = await svc.create_session(app_name="demo", user_id="alice")
  for i, value in enumerate(({"name": "Alice", "role": "admin"}, {"name": "Alice"})):
    await svc.append_event(s, Event(
        author="user", invocation_id=f"i{i}", timestamp=time.time(),
        actions=EventActions(state_delta={"user:profile": value})))
  print("same Session object right after update :", s.state["user:profile"])
  fresh = await svc.get_session(app_name="demo", user_id="alice", session_id=s.id)
  print("after reload (get_session)             :", fresh.state["user:profile"])

asyncio.run(main())
same Session object right after update : {'name': 'Alice'}
after reload (get_session)             : {'name': 'Alice', 'role': 'admin'}

Not proposed here, open questions:

  • The 4 remaining contract failures: three come from last_update_time using Firestore's
    server updateTime instead of the appended event's timestamp, which looks intentional after
    Firestore Session Service does not handle timestamp correctly聽#5632 / fix(firestore): populate last_update_time in list_sessions from Firestore updateTime聽#5642. The fourth is list_sessions(user_id=None), which needs a single-field
    collection-group index on sessions.appName; I would document that.
  • Should the CLI accept --session_service_uri firestore://... and
    --memory_service_uri firestore://...? Today an unregistered session scheme falls back to
    DatabaseSessionService and fails with ValueError: Invalid database URL format. I have a
    working services.py registration and can propose a built-in scheme if that is wanted.
  • Registering Firestore in tests/unittests/sessions/_conformance.py needs a stateful Firestore
    fake. I can do that as a follow-up.

Activity

  1. added
    services[Component] This issue is related to runtime services, e.g. sessions, memory, artifacts, etc
    on Sep 21, 2026
  2. changed the issue type fromtoon Sep 21, 2026
  3. surajksharma07 commented on Sep 21, 2026

    @surajksharma07
    Collaborator

    @vishal-bulbule Went through all seven points and see the same behaviour on v2.9.2 and current main, none of it is in a release yet so upgrading won't help.

    Until #7195 is merged a suggested workaround for anyone hitting this: import from the full module path, keep nested dicts out of user:/app: state (flat keys instead) and add each session to memory only once. Could you verify that holds up on your Firestore setup?

    Also before you mark #7195 ready it'd be good to re-run its tests once more on top of the latest main so the review goes smoothly.

  4. added 7 commits that reference this issue on Sep 22, 2026
    ff97e4a
    e8c91e2
    9b1df1e
    e19ea1c
    a03ef39
    ea48d7d
    082bfe5
  5. vishal-bulbule commented on Sep 22, 2026

    @vishal-bulbule
    ContributorAuthor

    Thanks for going through all seven.

    I rebased #7195 onto current main (3833976) and re-ran everything:

    • Firestore unit tests: 50 passed
    • Full unit suite: 15584 passed, 0 failed
    • mypy on the Firestore package and pre-commit: clean
    • Session contract suite against a real Firestore database: 27 passed, 4 failed, the same as before the rebase. The 4 are the last_update_time source (3 tests) and the collection-group index needed by list_sessions(user_id=None) (1 test), both left out of scope in this issue.

    #7195 is already marked ready for review, it was not opened as a draft.

    On the workaround, I ran one script against a real Firestore database, once on current main and once with #7195:

    # Point Workaround on current main With #7195
    1 Package import Full module path works Package import works
    2 Nested user: / app: state merged Flat keys work. A removed field reads as None rather than absent Nested dict is replaced
    3 after_timestamp filters on write time No workaround: both events returned Only the newer event returned
    4 get_user_state No workaround: NotImplementedError Supported
    5 Positional-filter UserWarning No workaround, harmless No warning
    6 Duplicate memories Adding each session once works (4 docs, re-adding makes 8) Re-adding keeps 4 docs
    7 add_events_to_memory No workaround: NotImplementedError Supported

    So the workaround holds for 1, 2 and 6. Points 3, 4, 5 and 7 need #7195.

  6. surajksharma07 commented on Sep 24, 2026

    @surajksharma07
    Collaborator

    @vishal-bulbule. Went through the diff and ran the Firestore tests on the branch: all 50 pass and 16 of them fail against the current main source so the new tests really do catch the old behaviour.

    Nothing under integrations/firestore has changed on main since 3833976 and v2.9.2 is still the latest release so your table stands: the workaround covers 1, 2 and 6 and 3, 4, 5 and 7 have to wait for #7195.

    One small thing for the review: an event added with add_events_to_memory without a session_id and later with one gets two different doc IDs so might be worth a line in the docstring.

    @DeanChensj could you take a look at #7195 when you get a chance? Its 2 workflows are still waiting for approval.

  7. vishal-bulbule commented on Sep 24, 2026

    @vishal-bulbule
    ContributorAuthor

    Thanks for running it yourself.

    Added the docstring note on add_events_to_memory, since the session ID is hashed into the entry ID:

    Re-adding an event with the same session ID overwrites its entry. The session ID is part of that entry's ID, so an event added without one and later added with one is stored twice; search_memory returns one copy.

    The second sentence is worth stating because search_memory de-duplicates on author, text and timestamp, so the extra document does not show up twice in results, only in the collection.

    The branch is rebased on main (3833976) and the 50 Firestore tests, the full unit suite, mypy and pre-commit all pass.

  8. surajksharma07 commented on Sep 25, 2026

    @surajksharma07
    Collaborator

    The docstring note reads well @vishal-bulbule and the second sentence matches what search_memory does since it drops repeats on (author, text, timestamp).

    Merged the updated branch (987a012) onto current main (9625b06): merges cleanly, the 50 Firestore tests pass and the same 16 still fail when run against main's own Firestore code so nothing has drifted since 3833976.

    Nothing else needed from your side. v2.9.2 is still the latest release so the workaround for 1, 2 and 6 stands until #7195 lands.

    @DeanChensj #7195 is ready for review whenever you get to it, the 2 workflows still need approval.

  9. added a commit that references this issue on Oct 8, 2026
    b0ffa24
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Labels

services[Component] This issue is related to runtime services, e.g. sessions, memory, artifacts, etc

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions