Interactions API: retrievable parent steps are omitted from continuation context; matching function results fail turn-order validation

Gemini API
1

We have a reproducible discrepancy in Gemini Interactions API stateful continuation on an existing conversation. The observable failure extends to ordinary text, not just function-result validation. We need help identifying what creates this state and tracing how the parent history is loaded.

Environment: gemini-3.1-flash-lite, direct HTTPS with OAuth, paid project, store:true. The function-result discrepancy reproduced on both /v1/interactions and /v1beta/interactions; the text-retention diagnostic used /v1/interactions. The standalone probes use PHP 8.4/cURL, one generic contract_echo function, buffered JSON, and a tiny synthetic result. They contain no application dispatcher or actual tool execution.

Reproduction against an affected retained interaction

  1. Continue from an affected completed interaction with a user message containing a new random marker. Use tool_choice:none and ask for a text-only acknowledgement. The response is completed.
  2. GET that new interaction. Verify its ID and parent link and verify that its saved user_input contains the marker.
  3. Reference the new interaction with previous_interaction_id. Ask contract_echo to return the marker from the previous user message, or MISSING if unavailable. Re-specify the same system instruction and tool declaration and use tool_choice:auto.
  4. The model returns MISSING. The reported prompt drops from 28,463 input tokens for the seed request to 84 for the recall request.
  5. GET the pending interaction. Its parent link is correct and its final saved step is the exact function call returned by POST.
  6. Submit a matching function_result with that pending ID, its exact function name/call ID, and {"ok":true}. The API returns HTTP 400: Please ensure that function response turn comes immediately after a function call turn. Got function response with name 'default_api:contract_echo'.
  7. Control: reference the original completed anchor, supply the exact retrieved seed steps followed by a typed user_input recall step explicitly. The marker is recalled correctly and input tokens are 28,488.
  8. Controls on a healthy ancestor and a fresh conversation retain their markers through normal ID-based continuation and complete the matching function-result exchange.

In a separate minimal function-result probe, referencing a pending interaction by ID fails while referencing its completed parent and appending the pending record’s exact steps plus the identical result succeeds. This reproduces on both API versions.

What has been checked

The stored parent/call IDs and function names match. The pending record ends in the matching function call. Tiny object results and different generic/application function names reproduce the discrepancy on affected state. Fresh conversations accept the original large application result. Buffered and streamed requests have both exhibited the function-result rejection. Explicitly copying the complete retrieved transcript into a new root has produced healthy continuations, so the visible transcript alone is not a sufficient trigger.

Limits and requested investigation

The reproduction currently requires an affected retained anchor; we have not isolated a clean-start synthetic sequence that reliably creates the state. Several fresh-history, large-context, mixed built-in-tool, and branching controls passed. Attempts to regenerate the original conversation also change model outputs, so they are not exact sequence reproductions. Cache/token-accounting differences were observed near two affected boundaries, but caching has not been established as the cause.

Please trace the affected interactions’ history resolution and prompt assembly: why does GET expose the saved user/function-call steps and correct parent links while continuation behaves as though that inherited content is absent? Does this correspond to a known state migration, retention, cache, or history-resolution defect? Which request or state transition creates the discrepancy, and what is the supported repair or fix?

We can supply original affected and healthy interaction IDs through a private support channel. This public report intentionally contains no credentials, raw interaction IDs, account/project identifiers, or application transcript content.