Summary
When OpenClaw's failover ladder routes a conversation that originated on a Gemini reasoning model into openai/gpt-5.4 (or other OpenAI Responses reasoning model), every attempt fails with:
400 Item 'msg_007a7ea07cbd38270069f3e02378448196b5d1d1af3815dfb9' of type 'message'
was provided without its required 'reasoning' item:
'rs_007a7ea07cbd38270069f3e021f60c8196884f5632b96248e3'.
The fallback safety net silently does not catch — every Gemini → OpenAI cross-provider replay in the affected conversation cascades to "all models failed."
This is structurally adjacent to #1126 (closed COMPLETED 2026-01-28), which fixed the inverse direction: Item 'rs_…' of type 'reasoning' was provided without its required following item. The fix from #1126 evidently doesn't cover the path where a message item references a reasoning parent that was never propagated. Either the existing fix has a gap, or this is a regression introduced by a later cross-provider replay change.
Build under test
OpenClaw 2026.5.3 (06d46f7) (the version that produced the captured journal lines below).
The maintainer is asked to confirm reproducibility on current main, since 2026-05-07 includes the closure of #77566 (Gemini cross-provider replay — opposite direction) and prior fixes #76832 (Codex Responses replay state, merged 2026-05-04) and #71684 (Copilot Codex reasoning IDs, merged 2026-04-25). None of those fixes obviously target the message ↦ reasoning direction documented here, but I haven't built main to verify.
Reproduction
- Configure a failover chain that includes a Gemini reasoning model first and an OpenAI Responses reasoning model second:
model_stack:
- google/gemini-3.1-pro-preview
- openai/gpt-5.4
- google/gemini-2.5-flash
- Run conversation turns on the Gemini model that produce reasoning blocks (any nontrivial agent task).
- Force a failover from Gemini (e.g., simulate a
429 from Gemini, or rely on a real billing-cap event).
- Observe each
openai/gpt-5.4 failover attempt's response.
Observed
Excerpt from Embedded agent failed before reply: All models failed (4) lines, repeated across many runs in the affected window:
openai/gpt-5.4: 400 Item 'msg_<sanitized>' of type 'message' was provided without its
required 'reasoning' item: 'rs_<sanitized>'. (format)
The (format) classification means the failover policy treats this as a transient format error and attempts the next sibling, but the next sibling on the chain is also a Gemini model and hits the same upstream condition. The OpenAI fallback, which should be the safety net, never recovers the conversation.
Expected
When forwarding a conversation to an OpenAI Responses reasoning model, the OpenAI provider should propagate both the message item and its referenced reasoning item, preserving the parent-child invariant that OpenAI's API enforces.
If the conversation history was authored by a Gemini model and the reasoning item is not available in the persisted form expected by OpenAI, the OpenAI provider should either:
- Synthesize a placeholder
reasoning item matching OpenAI's schema (analogous to Gemini's "skip_thought_signature_validator" fallback approach for the inverse direction), OR
- Strip the
message's reasoning reference before sending, accepting some loss of context, OR
- Surface a typed error earlier so the failover policy can short-circuit without retrying siblings that share the same upstream conversation.
Why filing
The Gemini → OpenAI fallback is the documented safety net for users who configure OpenAI as a failover for Gemini billing/quota. With this bug, the safety net silently does not catch, leading to "all models failed" results that surprise users who assumed configured fallbacks would work.
In one captured 7-day window of a real OpenClaw deployment, this bug defeated the OpenAI fallback for every Gemini → OpenAI failover attempt during a billing-cap cascade — contributing to a multi-hour cascade-failure pattern. (Same source incident motivates a separate sibling-billing-account failover bug; the two together compound.)
Related
Summary
When OpenClaw's failover ladder routes a conversation that originated on a Gemini reasoning model into
openai/gpt-5.4(or other OpenAI Responses reasoning model), every attempt fails with:The fallback safety net silently does not catch — every Gemini → OpenAI cross-provider replay in the affected conversation cascades to "all models failed."
This is structurally adjacent to #1126 (closed
COMPLETED2026-01-28), which fixed the inverse direction:Item 'rs_…' of type 'reasoning' was provided without its required following item. The fix from #1126 evidently doesn't cover the path where amessageitem references areasoningparent that was never propagated. Either the existing fix has a gap, or this is a regression introduced by a later cross-provider replay change.Build under test
OpenClaw 2026.5.3 (06d46f7)(the version that produced the captured journal lines below).The maintainer is asked to confirm reproducibility on current
main, since 2026-05-07 includes the closure of #77566 (Gemini cross-provider replay — opposite direction) and prior fixes #76832 (Codex Responses replay state, merged 2026-05-04) and #71684 (Copilot Codex reasoning IDs, merged 2026-04-25). None of those fixes obviously target themessage↦reasoningdirection documented here, but I haven't builtmainto verify.Reproduction
429from Gemini, or rely on a real billing-cap event).openai/gpt-5.4failover attempt's response.Observed
Excerpt from
Embedded agent failed before reply: All models failed (4)lines, repeated across many runs in the affected window:The
(format)classification means the failover policy treats this as a transient format error and attempts the next sibling, but the next sibling on the chain is also a Gemini model and hits the same upstream condition. The OpenAI fallback, which should be the safety net, never recovers the conversation.Expected
When forwarding a conversation to an OpenAI Responses reasoning model, the OpenAI provider should propagate both the
messageitem and its referencedreasoningitem, preserving the parent-child invariant that OpenAI's API enforces.If the conversation history was authored by a Gemini model and the
reasoningitem is not available in the persisted form expected by OpenAI, the OpenAI provider should either:reasoningitem matching OpenAI's schema (analogous to Gemini's"skip_thought_signature_validator"fallback approach for the inverse direction), ORmessage's reasoning reference before sending, accepting some loss of context, ORWhy filing
The Gemini → OpenAI fallback is the documented safety net for users who configure OpenAI as a failover for Gemini billing/quota. With this bug, the safety net silently does not catch, leading to "all models failed" results that surprise users who assumed configured fallbacks would work.
In one captured 7-day window of a real OpenClaw deployment, this bug defeated the OpenAI fallback for every Gemini → OpenAI failover attempt during a billing-cap cascade — contributing to a multi-hour cascade-failure pattern. (Same source incident motivates a separate sibling-billing-account failover bug; the two together compound.)
Related
COMPLETED2026-01-28. The fix from OpenAI Responses reasoning item replay causes 400 (missing following item) #1126 doesn't cover the direction documented here.fix(openai-codex): avoid stale Responses replay state. Merged 2026-05-04. Different surface (Codex-specific).fix(github-copilot): preserve reasoning IDs for Copilot Codex models. Merged 2026-04-25. Different surface (Copilot Codex).thoughtSignaturedropped on cross-provider replay (2026.5.3-1) #77566 — Gemini 3.x silent hang,thoughtSignaturedropped on cross-provider replay. ClosedCOMPLETED2026-05-07. Inverse direction (Gemini receiving from another provider).