Summary

OpenAI Responses-compatible routes that do not persist Responses items (store=false, or store stripped because a custom provider declares compat.supportsStore=false) can still replay prior Responses item ids on follow-up/tool-turn requests.

For custom Responses-compatible providers, those prior item ids are not available server-side, so the backend can reject follow-up requests with errors such as:

• 404 Item with id ... not found
• Items are not persisted when store is set to false

Impact

This can turn embedded replies or follow-up/tool-turn conversations into user-visible failures like Something went wrong while processing your request for custom OpenAI-compatible Responses providers.

Expected behavior

When the effective Responses request is non-persistent:

• do not replay previous Responses item ids;
• do not send stale reasoning/message/function_call item ids from prior Responses output;
• keep existing item-id replay behavior for store-enabled/persistent OpenAI Responses routes.

Actual behavior

The replay path may include prior Responses output item ids even when the effective request is non-persistent.

Fix PR

A scoped bugfix PR is already open with regression tests and redacted real-backend proof:

• PR: fix: skip Responses item id replay without store #89128