Azure AI Foundry Responses API: after one failed response (server_error), every request on the conversation fails identically — is the client expected to delete the persisted input items?

Question: When a response fails server-side, its input items remain persisted in the conversation. Is the client expected to delete them (i.e., items commit before generation by design), or is a conversation that permanently errors after one failure a service bug? Knowing which determines whether we implement cleanup-on-failure in our gateway or keep our current retry-and-abandon mitigation.

Environment: Azure AI Foundry, Sweden Central; model gpt-5.4; OpenAI v1 Responses API (POST /openai/v1/responses), streaming, with server-side conversations; requests set background: true and prompt_cache_retention: "24h".

Scenario: A conversation ran normally for ~20 turns (~213K tokens stored history, ~115 tool calls). On 2026-08-25 at 07:43:56 UTC one response failed with a transient server_error (request ID e47d3550-d8f3-4b8b-9964-73ed90ed6c60). The input itself was fine — the identical input succeeded after the recovery described below.

Result: Every subsequent request on that conversation failed identically — HTTP 500, error.code: server_error, usage all zeros — both through a versioned agent and via a minimal raw POST /openai/v1/responses (e.g. request ID 066428f3-2b34-4fd1-bc1d-478cc426e2c0, 07:45:29 UTC). Each failed retry persisted its own input message items into the conversation before failing. Verbatim error:

Response resp_…8d47ac5b5481908d7fbddd5e4b671b failed (status=Failed): code=server_error,
message=The server had an error processing your request. Sorry about that! You can retry
your request … (Please include the request ID e47d3550-d8f3-4b8b-9964-73ed90ed6c60 …)

Troubleshooting done: Recovery found by bisection — DELETE /openai/v1/conversations/{conversation_id}/items/{item_id} on the trailing msg_ items (the failed turns' persisted inputs; items with no response items after them) instantly and fully restored the conversation, which then replayed the full ~213K-token history with truncation: disabled without issue. This rules out context-window overflow, item content, reasoning items, large tool outputs, and agent version. Not ruled out: an interaction with prompt caching — with prompt_cache_retention: "24h", a cached prefix containing the failed turn's orphaned items would explain both the identical follow-up failures and why deleting those items (shortening the prefix to one cached while healthy) recovered.

Reproducibility: The trigger is a server-side failure, so we cannot reproduce it on demand; the poisoned state and its recovery were fully reproducible while the conversation existed.