Two small issues in preload_memory_tool.py, both present in 2.7.1 and on current main.
1. The query is taken from the first content part only. The tool reads the user's query from the first part of user_content and returns early when that part has no text. This produces two silent failures. If the first part is a file or image — the natural shape of "here is a document, answer using it and what you know about me" — the tool returns before searching, so memory contributes nothing. If an application prepends a short placeholder text part (a common workaround for providers that reject a leading non-text part), the early return does not fire and memory is instead searched for the placeholder rather than the user's actual question. Both cases degrade answer quality with no error surface.
Worth noting that the same module's memory-side helper already joins the text across all parts when rendering retrieved memories, so the "join every text part" idiom exists in the file; only the query side does not use it.
2. Retrieval failure is reported to the root logger. The module defines its own google_adk.* logger but the retrieval except path logs through the root logging module instead. Applications that configure logging by the google_adk namespace therefore never see it. Combined with the silent return, a memory backend that is down, misconfigured, or unauthorized is indistinguishable from "no memories matched" — the agent simply answers worse.
Fail-open on retrieval is the right behavior and I am not asking to reverse #3069; the request is only that the failure be observable — the module's own logger at minimum, so operators can alert on it.
Versions: observed on 2.7.1 and on main.
Not a Contribution: this report is provided for informational purposes only and is not intended as a Contribution under the Google CLA.
Two small issues in
preload_memory_tool.py, both present in 2.7.1 and on current main.1. The query is taken from the first content part only. The tool reads the user's query from the first part of
user_contentand returns early when that part has no text. This produces two silent failures. If the first part is a file or image — the natural shape of "here is a document, answer using it and what you know about me" — the tool returns before searching, so memory contributes nothing. If an application prepends a short placeholder text part (a common workaround for providers that reject a leading non-text part), the early return does not fire and memory is instead searched for the placeholder rather than the user's actual question. Both cases degrade answer quality with no error surface.Worth noting that the same module's memory-side helper already joins the text across all parts when rendering retrieved memories, so the "join every text part" idiom exists in the file; only the query side does not use it.
2. Retrieval failure is reported to the root logger. The module defines its own
google_adk.*logger but the retrievalexceptpath logs through the rootloggingmodule instead. Applications that configure logging by thegoogle_adknamespace therefore never see it. Combined with the silent return, a memory backend that is down, misconfigured, or unauthorized is indistinguishable from "no memories matched" — the agent simply answers worse.Fail-open on retrieval is the right behavior and I am not asking to reverse #3069; the request is only that the failure be observable — the module's own logger at minimum, so operators can alert on it.
Versions: observed on 2.7.1 and on
main.Not a Contribution: this report is provided for informational purposes only and is not intended as a Contribution under the Google CLA.