MALFORMED_FUNCTION_CALL on function-response continuation with large context (gemini-3.1-pro-preview, reproducible)

Environment: gemini-3.1-pro-preview via the OpenAI-compatible endpoint (also reproduced via google-genai SDK), Python 3.12.

Behavior: in a two-round tool-calling exchange, round 1 completes correctly … the model issues a clean function_call (finish_reason=STOP). After the function response is appended and the conversation is re-sent, round 2 consistently returns finish_reason=MALFORMED_FUNCTION_CALL with a single empty text part and no function-call payload. No error is raised; the caller receives an empty completion.

Conditions: triggers reliably when the conversation contains large, repetitive-text context (~8-16k tokens) and the function response re-injects a sizable content payload. In our runs it reproduced on 91/99 affected items on one task slice and deterministically on retry. Two structurally different (both spec-conformant) continuation formats hit the identical rejection, which is why we believe the fault is in the model/API rather than the client.

Expected: round 2 either answers as text or issues a well-formed follow-up function call; if the model’s turn is malformed, an error or retry signal rather than a silent empty completion.

Repro: minimal instrumented script (3 items, prints parts/finish_reason/usage per round) available on request.

Related prior reports of the same finish_reason, for triage context: #69488 (malformed call when the OUTGOING call’s arguments carry large text, 2.0 Flash) and #93630 (malformed initial call generation, 2.5 Flash on Vertex). This report differs in locus: round 1 completes cleanly (valid function_call, STOP); the failure occurs on the round-2 continuation after the function response is appended and re-sent, yielding an empty text part with no call payload. So this appears to be a third variant of the same state-machine failure class, on the response-continuation path, still present in gemini-3.1-pro-preview, and deterministic in our repro.