openclaw - 💡(How to fix) Fix [Bug]: Azure Responses session replay keeps msg id without required reasoning after fallback

Bug type

Provider/session replay bug

Summary

A persistent dashboard agent session can get stuck when azure-openai-responses/gpt-5.5 fails once and the session falls back to a non-Responses Azure model. After switching back to azure-openai-responses/gpt-5.5, OpenClaw replays a previous msg_* Responses message item without the paired reasoning item, so Azure rejects the next turn before content is produced.

This is related to #84484, but the trigger observed here is an Azure Responses session that temporarily fell back from azure-openai-responses/gpt-5.5 to azure-openai/gpt-5.4, then resumed GPT-5.5 in the same session.

Environment

• OpenClaw version: 2026.5.27 (27ae826)
• Runtime: gateway/dashboard agent session
• OS: Ubuntu 24.04 under WSL
• Primary/default model: azure-openai-responses/gpt-5.5
• Fallback/stable model used during recovery: azure-openai/gpt-5.4

Observed behavior

The dashboard showed:

[assistant turn failed before producing content]

The underlying provider error was:

400 Item 'msg_...' of type 'message' was provided without its required 'reasoning' item: 'rs_...'

A fresh azure-openai-responses/gpt-5.5 agent turn worked, so this was not a general provider/auth/config failure. The failure was scoped to one existing dashboard session history.

Local diagnosis

The affected session history contained successful earlier azure-openai-responses/gpt-5.5 assistant messages with reasoning replay metadata. Later, the session switched/fell back to azure-openai/gpt-5.4. When the session was switched back to azure-openai-responses/gpt-5.5, the next turn failed before producing content.

The behavior looked like the replay builder treated the turn as a model/provider switch and did not include the original Responses reasoning item, but still preserved/replayed the associated Responses message id (msg_*). Azure then correctly rejected the input because that message id requires the paired rs_* reasoning item.

Adding a clean final model snapshot for azure-openai-responses/gpt-5.5 and removing the failed diagnostic turns allowed the same dashboard session to run on GPT-5.5 again. Switching the global default to azure-openai/gpt-5.4 also avoided the immediate failure, but that is only a workaround and disables the desired GPT-5.5 path.

Expected behavior

When resuming a Responses-family model after fallback/model switching, OpenClaw should build a provider-valid replay input. In particular, it should either:

1. preserve and replay the required reasoning item whenever it preserves the paired msg_* item id;
2. strip both the msg_* id and incompatible reasoning state together when replay compatibility fails; or
3. compact/sanitize the session history before retrying so the session does not remain permanently stuck.

A transient fallback from azure-openai-responses/gpt-5.5 to azure-openai/gpt-5.4 should not poison the persistent session for future GPT-5.5 turns.

Workaround used locally

• Kept the default model as azure-openai-responses/gpt-5.5.
• Cleaned the affected session history after the last good real user turn.
• Appended a clean model-snapshot for azure-openai-responses/gpt-5.5.

After that, a fresh GPT-5.5 agent turn and the repaired dashboard session worked again.