FirestoreSessionService ignores `app:` / `user:` state prefixes, so app and user state are never shared across sessions
Mantenedores costumam responder em até 1 dia
Avaliação
- Dificuldade
- 4/5
- Tempo estimado
- 3-5 dias
- Facilidade para iniciantes
- 45/100
Direção de pesquisa
Start with appendEvent in contrib/firestore-session-service's FirestoreSessionService.java (prefix split around L657-L689, removal check at L666), then getSession (around L262-L272), and compare with InMemorySessionService.java appendEvent (L316-L338) and mergeWithGlobalState (L398). Run the module's existing mocked tests to see how app-state and user-state writes are asserted. Done means app: and user: keys are shared across sessions and merged on read, temp: keys are not persisted, and State.REMOVED deletes the key.
Escrita pelo modelo de indexação a partir do texto da issue.
Descrição
🔴 Required Information
Describe the Bug:
FirestoreSessionService does not implement ADK's scoped state. ADK's State class defines app:, user: and temp: prefixes (State.APP_PREFIX, USER_PREFIX, TEMP_PREFIX), and InMemorySessionService stores app:/user: keys in shared app/user stores and merges them back into every session. FirestoreSessionService behaves differently:
appendEventonly routes keys starting with_app_/_user_to theapp-state/user-statecollections. Keys written through the normal ADK API (app:theme,user:name) fall through to the per-sessionstatefield, so they are only visible in that one session.- The
app-stateanduser-statecollections are write-only.getSession,createSessionandlistSessionsnever read them, so even a value stored under_app_/_user_never reaches another session. temp:keys are persisted in the session document.BaseSessionService.appendEventskips them.- Removal checks
value == null, but ADK marks removals with theState.REMOVEDsentinel, so a removed key is kept and the sentinel object is written to the session'sstatemap instead of the key being deleted.
Code references (main @ 189d463):
contrib/firestore-session-service/.../FirestoreSessionService.javaappendEvent(prefix split around L657-L689, removal check L666)getSessionbuilds the session only from the session document'sstatefield (around L262-L272)- Compare
core/.../InMemorySessionService.javaappendEvent(L316-L338) andmergeWithGlobalState(L398)
Steps to Reproduce:
- Configure a runner with
FirestoreSessionService. - In session A, a tool or callback sets
context.state().put("user:name", "Jae"). - Create session B for the same app and user, and read
user:name.
The same can be shown with the module's existing mocked tests (no Firestore needed): appending an event with state delta {"app:theme": "dark", "user:name": "Jae"} never calls set on the app-state / user-state documents, and the session document is updated with state = {app:theme=dark, user:name=Jae}. Appending {"temp:scratch": "x", "gone": State.REMOVED} writes both temp:scratch and the REMOVED sentinel into the session's state.
Expected Behavior:
Same semantics as InMemorySessionService (and the Python ADK database session services): app: keys shared by all sessions of the app, user: keys shared by all sessions of the app and user, merged back into Session.state() on getSession / createSession / listSessions, temp: keys not persisted, and State.REMOVED deleting the key.
Observed Behavior:
In session B, user:name is missing. App/user state behaves like session state. temp: values persist, and removed keys are not deleted.
Environment Details:
- ADK Library Version: main @ 189d463 (1.11.1-SNAPSHOT),
google-adk-firestore-session-service - OS: Linux
- TS Version: N/A
Model Information:
- N/A (session service bug, model independent)
🟡 Optional Information
Regression: No. The _app_ / _user_ handling has been there since the Firestore service was added.
Additional Context:
A fix would (a) split on State.APP_PREFIX / State.USER_PREFIX, (b) merge the app-state / user-state documents back into the session state with the prefixes on read, (c) skip State.TEMP_PREFIX, and (d) treat State.REMOVED as a delete (FieldValue.delete() in the shared stores). Existing data stored under _app_ / _user_ keys (if anyone relied on that convention) may need a note in the changelog. I'm happy to send a PR if this direction looks right.
- Linguagem predominante
- Java
- Estrelas
- 1.7k
- Forks
- 433
- Merge médio
- 3d 11h
- PRs com merge (30d)
- 57
Preparar o ambiente
Inicia o contêiner de desenvolvimento do projeto no navegador, com a sua própria conta do GitHub.
- Sem Dockerfile nem arquivo Docker Compose
- Tem um modelo de pull request
- Ler o guia de contribuição
Primeiros passos
- Leia a issue inteira e depois o guia de contribuição do projeto.
- Comente na issue dizendo que vai assumir — evita que duas pessoas façam o mesmo trabalho.
- Faça um fork do repositório e trabalhe em uma branch.
- Abra um pull request que referencie o número da issue.
Mais de google/adk-java
-
GeminiUtil placeholder user turn ("Continue output. DO NOT look at this line ...") is flagged by prompt injection filtersTalvez já em andamento @hemasekhar-p assumiu há 7 dias. Abertaneeds review
Dificuldade 2/5 1-3 horas Facilidade para iniciantes 76/100
google/adk-java#1628 · 1 comentário · 1 responsável ·
Mantenedores costumam responder em até 1 dia
-
[spring-ai] Streaming responses ending with CJK punctuation (。!?) are misclassified as partial and never persisted to the sessionTalvez já em andamento @hirematha assumiu há 10 dias. Abertaneeds review
Dificuldade 2/5 1-3 horas Facilidade para iniciantes 84/100
google/adk-java#1608 · 3 comentários · 1 responsável ·
Mantenedores costumam responder em até 1 dia
-
VertexAiSessionService: Event.id differs between the streamed event and getSession (id is not sent to Vertex and the appendEvent response is empty)Talvez já em andamento @hemasekhar-p assumiu há 2 dias. Abertawaiting on reporter
Dificuldade 4/5 3-5 dias Facilidade para iniciantes 45/100
google/adk-java#1651 · 2 comentários · 1 responsável ·
Mantenedores costumam responder em até 1 dia
-
runLive passes partial events to appendEvent and never aggregates text chunks, unlike ADK PythonTalvez já em andamento @hemasekhar-p assumiu há 3 dias. Abertaneeds review
Dificuldade 4/5 3-5 dias Facilidade para iniciantes 45/100
google/adk-java#1648 · 3 comentários · 1 responsável ·
Mantenedores costumam responder em até 1 dia
-
FirestoreSessionService compares event timestamps as text, reordering or skipping same-second eventsTalvez já em andamento @hemasekhar-p assumiu há 3 dias. Abertaneeds review
Dificuldade 3/5 1-2 dias Facilidade para iniciantes 50/100
google/adk-java#1646 · 3 comentários · 1 responsável ·
Mantenedores costumam responder em até 1 dia
Todas as issues de google/adk-java
Issues semelhantes
-
area/plugin good first issue
Dificuldade 2/5 1-3 horas Facilidade para iniciantes 85/100
kestra-io/plugin-soda#137 ·
-
area/plugin good first issue
Dificuldade 2/5 1-3 horas Facilidade para iniciantes 82/100
kestra-io/plugin-aws#816 ·
Mantenedores costumam responder em até 2 dias
-
area/plugin good first issue
Dificuldade 2/5 1-3 horas Facilidade para iniciantes 88/100
kestra-io/plugin-kestra#200 ·
Mantenedores costumam responder em até 1 dia
-
bug untriaged
Dificuldade 1/5 Menos de uma hora Facilidade para iniciantes 92/100
opensearch-project/search-relevance#618 ·
Mantenedores costumam responder em até 3 dias
-
[Studio][Bug] Invalid ACL wildcard entries inflate the risk scoreTalvez já em andamento Um pull request vinculado a esta issue está aberto ou já foi mesclado. Aberta
Dificuldade 2/5 1-3 horas Facilidade para iniciantes 72/100
apache/rocketmq-dashboard#6716 ·
Mantenedores costumam responder em até 3 dias