Intermittent server-side failures of multi-turn image editing on BOTH the generateContent and Interactions APIs — chaining 404 not_found + spurious 400 "Image part is missing a thought_signature" — affecting all image models, with gemini-3.1-flash-image hit hardest (near-total multi-turn outage 2026-06-25 → 2026-07-04; Interactions chaining on flash-image broken again as of 2026-07-05)
Summary
(Last verified with fresh controlled probes: 2026-07-05.)
Multi-turn image editing fails intermittently at the server side, in two distinct signatures, on every image model (gemini-3.1-flash-image, gemini-3.1-flash-lite-image, gemini-3-pro-image) and on both API surfaces:
404 NOT_FOUND / not_found(“Requested entity was not found”) when the server must resolve prior-turn state:generateContentchat-history replay (turn 2+ ofclient.chats), and Interactionsprevious_interaction_idchaining.400 invalid_request(“Image part is missing a thought_signature in content position X, part position Y”) on client-managed Interactions replay — thrown against payloads that demonstrably carry the correct signature at the flagged position, and usually cleared by an identical, immediate retry (though also observed persisting across 3 consecutive identical attempts).
Both are per-request and fleet-state-dependent: failure rates for the same payload swing from 0% to ~100% and back within hours, with no client change. gemini-3.1-flash-image is particularly susceptible — for it, the failure was near-deterministic for nine days (2026-06-25 → 2026-07-04, ~90% of conversations), constituting an outage of the documented, “fully supported” multi-turn image-editing pattern. That outage cleared server-side midday 2026-07-04 — and has already partially recurred: as of 2026-07-05, generateContent multi-turn is healthy on all three models, but Interactions previous_interaction_id chaining on flash-image is failing again (0/3 fresh chains; interactions.get() succeeds for the very ids that fail to chain), and the spurious signature-400 remains live — now also observed persisting across 3 consecutive identical retries. Single-turn generation is unaffected throughout, on all models.
Failure signatures (exact)
google.genai.errors.ClientError: 404 NOT_FOUND.
{'error': {'code': 404, 'message': 'Requested entity was not found.', 'status': 'NOT_FOUND'}}
BadRequestError: Error code: 404 - {'error': {'message': 'Requested entity was not found.',
'code': 'not_found'}} # Interactions chaining
BadRequestError: Error code: 400 - {'error': {'message': 'Image part is missing a
thought_signature in content position 2, part position 1. ...', 'code': 'invalid_request'}}
Environment
- Models:
gemini-3.1-flash-image(primary),gemini-3.1-flash-lite-image,gemini-3-pro-image - APIs:
generateContent(viaclient.chats) AND Interactions (client.interactions.create, bothprevious_interaction_idchaining and client-managed step-array replay withstore=false) - SDK:
google-genai(multiple versions tested up to 2.10.0 — upgrade/downgrade has no effect, consistent with a server-side cause). Python 3.12/3.13. - Endpoint:
generativelanguage.googleapis.com, API-key auth (paid tier 2)
Timeline of controlled observations (all same key/project, no client changes within each window)
| When | Observation |
|---|---|
| ≤ 2026-06-24 | generateContent multi-turn image editing in production for weeks, no incident. |
| 2026-06-25 | Onset: turn 2+ of chats replay on gemini-3.1-flash-image starts failing 404 for ~90% of conversations (intermittent successes). Code verifiably unchanged (VCS). |
| 2026-06-29 | Behavior flips mid-run across all in-flight conversations — impossible from the client side. |
| 2026-07-04 am | Interactions probes: previous_interaction_id chaining on flash-image fails 0/6 while interactions.get(<id>) succeeds for the same ids (storage healthy; chaining/state resolution broken) and a 10 s delayed retry still 404s. Sibling models chain 3/3. The legacy chats pattern also works on the siblings (2/2 each, 3-turn) — same code shape. |
| 2026-07-04 am | Client-managed replay on flash-image: replaying the response’s thought step verbatim → the same 404; moving the signature onto the replayed image part works — intermittently rejected by the spurious 400 missing thought_signature, cleared by identical retry. |
| 2026-07-04 midday | Flash-image clears with no client change: legacy chats 5/5 (incl. 3-turn), Interactions chaining 2/2 — the 9-day fault vanishes as abruptly as it appeared. |
| 2026-07-04 pm | The signature validator runs hot: across 4 fresh-seed probe runs × 5 replay payload shapes (image-only with either thought signature; ± the text step, signed or unsigned; combined step), EVERY shape alternates OK ↔ the same 400 run-to-run (~50%). Reproduced on flash-lite-image (1/3); observed on a chained call as well (signature validation applies server-side to chained state too). |
| 2026-07-04 pm | Production session on gemini-3-pro-image: chaining 404s repeatedly; controlled probes minutes later show pro→pro chaining healthy (2/2) and cross-model chaining works (heads minted by flash/flash-lite chain fine under pro) — confirming per-request intermittency rather than any model- or payload-scoped rule. |
| 2026-07-05 | Chaining fault recurs on flash-image (Interactions only). Fresh matrix, same key, no client changes: generateContent 3-turn chats pass 7/7 across all three models (the legacy surface stays healed) — but Interactions previous_interaction_id chaining on flash-image fails 0/3, turn 2 404 not_found while interactions.get(turn1.id) succeeds for the same id and a 10 s delayed retry still 404s. Sibling models chain 2/2 each. |
| 2026-07-05 | Signature validator still flaking. Client-managed signed replay (image-only parts, correct per-turn signatures): one 3-turn conversation passes clean; a second, identical run fails turn 2 with the spurious 400 missing thought_signature on 3 consecutive identical attempts seconds apart — the first observed instance of the flake NOT clearing within a 3-attempt retry budget. Replay-shape probes the same hour: image-only and combined text+image single-step shapes pass; text-bearing multi-step shapes (signed or unsigned text) 400 — a different acceptance pattern than 07-04, when every shape alternated ~50%. |
Minimal reproductions
generateContent (the original outage shape):
chat = client.chats.create(
model="gemini-3.1-flash-image",
config=types.GenerateContentConfig(
response_modalities=["TEXT", "IMAGE"],
image_config=types.ImageConfig(aspect_ratio="2:3", image_size="2K"),
),
)
r1 = chat.send_message(["Recreate this page with the headline text changed.", source_pil]) # OK
r2 = chat.send_message(["Now change the red circle to a blue square."]) # -> 404 (intermittent)
Interactions chaining:
i1 = client.interactions.create(model=M, input=[text, image], response_format=RF) # OK
i2 = client.interactions.create(model=M, input="edit it", previous_interaction_id=i1.id,
response_format=RF) # -> 404 not_found (intermittent)
# while client.interactions.get(i1.id) succeeds for the same id
Interactions client-managed replay:
client.interactions.create(model=M, response_format=RF, store=False, input=[
{"type": "user_input", "content": [text, image]},
{"type": "model_output", "content": [
{"type": "image", "data": r1_img_b64, "mime_type": "image/jpeg",
"thought_signature": r1_thought_signature}]}, # signature present & correct
{"type": "user_input", "content": [{"type": "text", "text": "edit it"}]},
]) # -> 400 "Image part is missing a thought_signature ..." (intermittent, ~50% at peak)
Why we believe this is server-side (client causes ruled out)
- No client-managed server resources in the payloads: all history parts are inline text/bytes; no Files API objects anywhere in these conversations — nothing of ours that could expire or be deleted between turns.
- The only server-issued state involved is thought-signature/interaction state: the 404s occur exactly where the server must resolve it (chat replay, chaining, replayed signatures), while
get()retrieval and single-turn generation never fail. - Identical requests flip between success and failure — including the same payload retried within seconds, and the same code shape probed hours apart flipping 0/6 → 2/2 (chaining) and OK ↔ 400 across all five replay shapes.
- Timing: the 06-25 onset, the 07-04 recovery, and the 07-05 recurrence (Interactions chaining on flash-image broken again while
generateContentstays healthy) all occurred with zero client-side changes (VCS-verified), once flipping mid-run across in-flight conversations. - Reproduced from clean environments across SDK versions; key, project, quota and billing unchanged throughout.
Taken together: the state/validation subsystem behind image-model thought signatures appears to be in an inconsistently-rolled-out state across the fleet — requests land on healthy or unhealthy replicas at random, with gemini-3.1-flash-image having spent nine days almost entirely unhealthy, and its Interactions chaining path unhealthy again as of 2026-07-05.
Expected behavior
Multi-turn image editing behaves as documented on both APIs: chat replay / chaining resolves prior state, and correctly-signed replayed parts pass validation — or, if something about the request is genuinely wrong, the error is deterministic and actionable rather than intermittent.
Impact
High production impact. Multi-turn image refinement (iterative generate→edit conversations) is a core capability of our production application; during the flash-image outage we had to disable the affected feature behind a kill switch, with visible quality loss for users. We have since migrated to the Interactions API with client-managed signed replay, retry budgets sized for the flake, and context-rebuild fallbacks — but at peak flake rates (~50%/request) even 3 attempts fail ~12% of invocations, and on 2026-07-05 we observed a correctly-signed request rejected on 3 consecutive identical attempts, i.e. retry budgets do not reliably absorb the fault. The docs state generateContent “remains fully supported” and the Interactions API is the recommended path; both exhibit the same instability for image-model multi-turn state, and as of 2026-07-05 the Interactions chaining path is the one broken on flash-image while generateContent happens to be healthy — the reverse of 2026-06-25 → 2026-07-04.
Questions
- Is the intermittent failure of image-model multi-turn state resolution (404s) and thought- signature validation (spurious 400s) a known issue, and is a fix planned? What was the root cause of the 2026-06-25 → 2026-07-04
gemini-3.1-flash-imageoutage? It evidently was not fixed permanently — flash-imageprevious_interaction_idchaining is failing again as of 2026-07-05 (get()healthy, chaining 404). - Should clients treat
400 "Image part is missing a thought_signature"as retryable? It is documented as a request-validation error, but it fires against correctly-signed payloads and usually clears on identical retry — though we have now also observed it persist across 3 consecutive identical attempts, so a bounded retry is not a reliable mitigation either. - Is there a status-page / changelog channel where server-side regressions of documented API behavior are announced? Nine days of a near-total multi-turn outage on a “fully supported” pattern passed without any public notice we could find.