Thanks for this — the redundant get_session fan-out in #1880 is real and the per-execution ContextVar design (isolated per concurrent run, seeded on create/find) is a nice way to collapse it. Before merging, though, I think the cache currently outlives the window it's safe in, and serves stale data on the normal-turn path.

The problem: the ADK runner writes to the session service without going through SessionManager.

_create_runner builds the Runner with session_service=self._session_manager._session_service (adk_agent.py L1104) — the same service the cache wraps. When runner.run_async (L2626) runs the agent, ADK persists the LLM responses, tool calls, and state deltas via session_service.append_event(...) directly. Those writes never touch SessionManager, so invalidate_session never fires for them — but the cache (started at L1796 and torn down only in _start_new_execution's finally) stays open across the entire runner execution.

On a plain user-message turn that means:

1. L2238 update_session_state → invalidates
2. L2243 get_session → re-seeds the cache with the pre-run session
3. L2626 runner mutates the store directly — no invalidation
4. L2877 get_session_state → cache hit → stale → feeds STATE_SNAPSHOT
5. L2912 get_session → cache hit → stale → feeds MESSAGES_SNAPSHOT (right under the # Refresh session to get latest events comment — the cache defeats the refresh that line exists to do)

So the run's STATE_SNAPSHOT drops state the agent set, and MESSAGES_SNAPSHOT is missing the agent's reply. It's worst on long / subsequent turns — the exact case the PR is optimizing. The HITL tool-result branches happen to dodge it (their post-append invalidate_session leaves the cache empty before the runner), but the common path doesn't. The existing integration tests that would catch this need a live LLM and are currently red on main for unrelated reasons (decommissioned gemini-2.0-flash), so the unit tests passing doesn't rule it out.

Minimal repro against a real InMemorySessionService, simulating the runner's direct append_event inside the cache window:

token = mgr.start_session_read_cache()
pre = await mgr.get_session_state(sid, app, uid)            # seeds cache
sess = await svc.get_session(app_name=app, user_id=uid, session_id=sid)
await svc.append_event(sess, Event(author="agent", invocation_id="i",
    content=types.Content(role="model", parts=[types.Part(text="hi")]),
    actions=EventActions(state_delta={"counter": 99})))     # runner-style write
final = await mgr.get_session_state(sid, app, uid)           # cache hit
mgr.stop_session_read_cache(token)
# final["counter"] == 0, ground truth == 99   -> stale
# cached session.events == 0, ground truth == 1 -> stale MESSAGES_SNAPSHOT

Suggested fix: scope the cache to the pre-run phase only. The issue notes the redundancy is "all before the agent runs", so the cache never needs to span the runner. Tear it down right before the runner.run_async loop (L2626) so every post-run read goes back to the live service. That keeps the full win (the pre-run get_session/get_state_value/_has_pending_tool_calls reads still collapse to one fetch) without ever serving a session the runner has since mutated.

One implementation note: the teardown has to happen inside _run_adk_in_background (that's where the runner lives), not in _start_new_execution. Since the background task is spawned via create_task (L2127) it holds its own copy of the context, and ContextVar.reset(token) is bound to the context that created the token — so reuse won't work cleanly here. Simplest is a tokenless teardown that just disables caching for the rest of the bg task, e.g.:

def disable_session_read_cache(self) -> None:
    """Disable the per-execution read cache for the remainder of this context."""
    _SESSION_READ_CACHE.set(None)

called immediately before the runner loop. The parent's existing stop_session_read_cache(token) in the finally then remains a harmless reset in its own context.

(If you'd rather keep the cache live across the run, the alternative is to invalidate_session(backend_session_id, …) right after the runner — but that's more fragile, since it relies on enumerating every out-of-band writer. Scoping to pre-run is the lower-risk option.)

@he-yufeng Thanks! Scoping the cache to pre-run with disable_session_read_cache() before runner.run_async fixes the STATE_SNAPSHOT / MESSAGES_SNAPSHOT staleness in the background task. I ran the live suite (real Gemini on gemini-3.5-flash, plus the live Vertex Agent Engine session tests) and that path is solid now.

We're getting real close now if you wouldn't mind bearing with me - there's one more spot the same root cause reaches, though, and I was able to reproduce it live.

disable_session_read_cache() only disables the cache in the background task's context : _start_new_execution (the parent) keeps its own live cache, and it does a post-run read.

_run_adk_in_background is spawned via asyncio.create_task (adk_agent.py L2127), so it runs with a copy of the parent context. The disable call at L2626 sets the ContextVar to None in that copy only. The parent's ContextVar still points at the seeded cache dict. And the parent's finally does a post-run read that the runner's out-of-band writes have invalidated: _has_pending_tool_calls at L1897, the HITL guard that decides whether to evict the execution from _active_executions.

So on a HITL turn, the pending-tool-call write lands in the store during the run, but the parent's guard reads the stale pre-run cache and sees no pending calls — and deletes the execution that the guard exists specifically to preserve.

Reproduced live (real Gemini + DatabaseSessionService, resumable app, single HITL turn), instrumenting the parent's cleanup read vs. the store:

tool calls emitted     : ['klt5ridb']
cache active in parent : True
parent cleanup saw     : False    <- stale, cache-served
store ground truth     : True     <- pending call IS persisted

The new test_hitl_client_tool_live_llm_with_database_session_service doesn't catch this because it asserts against session_service.get_session(...) directly (the store), not the in-memory _active_executions cleanup decision.

This isn't specific to DatabaseSessionService — it applies to any backend the runner writes through without going via SessionManager, including the VertexAiSessionService case from #1880.

Suggested fix: drop the parent's cache before that post-run read. Since the parent owns the token, the simplest is to disable at the top of the finally:

finally:
    try:
        # The runner mutated the session outside SessionManager, so the
        # pre-run read cache in THIS (parent) context is now stale. Drop it
        # before the post-run pending-tool-calls read below, otherwise the
        # HITL cleanup guard reads a stale "no pending calls".
        self._session_manager.disable_session_read_cache()
        # Clean up execution if complete and no pending tool calls (HITL scenarios)
        async with self._execution_lock:
            ...
            has_pending = await self._has_pending_tool_calls(input.thread_id, user_id)
            ...
    finally:
        self._session_manager.stop_session_read_cache(session_cache_token)

(Reordering so stop_session_read_cache(session_cache_token) runs before _has_pending_tool_calls would also work, since reset returns the var to its None default.)

With this change the re-probe shows parent cleanup saw: True (agrees with the store), and the HITL / session-memory / resumability suites stay green (69 passed). Worth a small regression test that asserts _active_executions still contains the entry after a HITL turn with a pending tool call — the existing tests only check store persistence, so this gap would otherwise stay invisible.

Again, thanks for your work on this one - it's turned out to be gnarlier than most - but I'm hyper-vigilant on anything dealing with tool calls and session state because that's where so many regressions pop up.

@he-yufeng Looks good! Thank you for your efforts.