Context cache application can empty llm_request.contents, Gemini rejects with 'contents are required.'

[anmolg1997]

Describe the bug

GeminiContextCacheManager._apply_cache_to_request removes the cached prefix from the request with an unguarded slice:

# google/adk/models/gemini_context_cache_manager.py (v2.8.0, line 671)
llm_request.contents = llm_request.contents[cache_contents_count:]

When cache_contents_count >= len(llm_request.contents), the slice leaves zero contents, and the subsequent generate_content call is rejected by the Gemini API with contents are required. — the model call fails even though a perfectly valid cache exists.

How it happens in practice

We hit this in production with an include_contents='none' agent (a planner that receives one injected user content per call) in a long-lived session:

1. Turn N: the agent's single injected content gets cached (contents_count = 1).
2. Turn N+1 (cache REUSE path, fingerprint valid): the request again carries exactly 1 content; _apply_cache_to_request slices contents[1:] → [].
3. Gemini rejects the call: contents are required. The turn fails to plan.

Any topology where the cacheable prefix count equals the current request's content count reproduces it; include_contents='none' agents just make it common.

Expected behavior

Applying a cache should never produce an empty contents list. Either clamp the slice so at least the last content survives, or skip cache application when it would empty the request.

We currently carry this wrapper in production, which would be trivial to inline upstream:

before = list(llm_request.contents or [])
_original_apply(self, llm_request, cache_name, cache_contents_count)
if not llm_request.contents and before:
    llm_request.contents = [before[-1]]

Related

#6363 covered the inverse edge (cache_contents_count == 0 at creation); this one is the application-time over-slice on reuse.

Environment

• google-adk 2.8.0 (also present in 2.6.3 and 1.3x)
• Model: gemini-2.5-flash family via the native Gemini path, explicit context caching enabled through ContextCacheConfig

[linhongyu510]

I reproduced this on current main without a model call: when cache_contents_count == len(llm_request.contents), _apply_cache_to_request() leaves contents=[] while setting cached_content, which produces an invalid downstream Gemini request. The existing focused cache-manager suite passes (46 tests), so this boundary currently has no regression coverage.

I would like to work on a small fix if the direction is acceptable. My proposed scope is:

1. keep at least the final content in the live request when applying a cache would otherwise empty it;
2. add isolated unit coverage for the equal-count boundary and normal partial-prefix behavior;
3. run the focused suite, full unit suite, pre-commit, and provide a manual request-shape validation in the PR.

Could a maintainer confirm that preserving the final content is the intended behavior, rather than skipping cache reuse for this case? I will wait for confirmation before opening a PR, per CONTRIBUTING.md.