You've already forked adk-python
mirror of
https://github.com/encounter/adk-python.git
synced 2026-03-30 10:57:20 -07:00
aa1233608a
Merge https://github.com/google/adk-python/pull/2447 This PR corrects misspellings identified by the [check-spelling action](https://github.com/marketplace/actions/check-spelling) The misspellings have been reported at https://github.com/jsoref/adk-python/actions/runs/16840838898/attempts/1#summary-47711379253 The action reports that the changes in this PR would make it happy: https://github.com/jsoref/adk-python/actions/runs/16840839269/attempts/1#summary-47711380479 Note: while I use tooling to identify errors, the tooling doesn't _actually_ provide the corrections, I'm picking them on my own. I'm a human, and I may make mistakes. I've included a couple of changes to make CI happy. Personally, I object to CI being in a state of "random drive by person who adds a blank line in the middle of a file must fix all the preexisting bugs in the file", but that appears to be the state for this repository. COPYBARA_INTEGRATE_REVIEW=https://github.com/google/adk-python/pull/2447 from jsoref:spelling d85398e7fd154d124d477c6af6181481a01f34e0 PiperOrigin-RevId: 827629615
Sample Agent to demo session state persistence.
Lifecycle of session state
After assigning a state using the context object (e.g.
tool_context.state['log_query_var'] = 'log_query_var_value'):
- The state is available for use in a later callback.
- Once the resulting event is processed by the runner and appended in the session, the state will be also persisted in the session.
This sample agent is for demonstrating the aforementioned behavior.
Run the agent
Run below command:
$ adk run contributing/samples/session_state_agent --replay contributing/samples/session_state_agent/input.json
And you should see below output:
[user]: hello world!
===================== In before_agent_callback ==============================
** Asserting keys are cached in context: ['before_agent_callback_state_key'] pass ✅
** Asserting keys are already persisted in session: [] pass ✅
** Asserting keys are not persisted in session yet: ['before_agent_callback_state_key'] pass ✅
============================================================
===================== In before_model_callback ==============================
** Asserting keys are cached in context: ['before_agent_callback_state_key', 'before_model_callback_state_key'] pass ✅
** Asserting keys are already persisted in session: ['before_agent_callback_state_key'] pass ✅
** Asserting keys are not persisted in session yet: ['before_model_callback_state_key'] pass ✅
============================================================
===================== In after_model_callback ==============================
** Asserting keys are cached in context: ['before_agent_callback_state_key', 'before_model_callback_state_key', 'after_model_callback_state_key'] pass ✅
** Asserting keys are already persisted in session: ['before_agent_callback_state_key'] pass ✅
** Asserting keys are not persisted in session yet: ['before_model_callback_state_key', 'after_model_callback_state_key'] pass ✅
============================================================
[root_agent]: Hello! How can I help you verify something today?
===================== In after_agent_callback ==============================
** Asserting keys are cached in context: ['before_agent_callback_state_key', 'before_model_callback_state_key', 'after_model_callback_state_key', 'after_agent_callback_state_key'] pass ✅
** Asserting keys are already persisted in session: ['before_agent_callback_state_key', 'before_model_callback_state_key', 'after_model_callback_state_key'] pass ✅
** Asserting keys are not persisted in session yet: ['after_agent_callback_state_key'] pass ✅
============================================================
Detailed Explanation
As rule of thumb, to read and write session state, user should assume the
state is available after writing via the context object
(tool_context, callback_context or readonly_context).
Current Behavior
The current behavior of persisting states are:
- for
before_agent_callback: state delta will be persisted after all callbacks are processed. - for
before_model_callback: state delta will be persisted with the final LlmResponse, aka. afterafter_model_callbackis processed. - for
after_model_callback: state delta will be persisted together with the event of LlmResponse. - for
after_agent_callback: state delta will be persisted after all callbacks are processed.
NOTE: the current behavior is considered implementation detail and may be changed later. DO NOT rely on it.