Summary

Current main still replays prior Responses item ids for a custom OpenAI Responses-compatible provider that does not support Responses store.

The previously referenced fix commit, 03dec8bb3a00209780d3140ec3f10ad0eb069030, is included in current main, but it does not cover this storeless compatibility path.

Related prior report:

• Follow-up to Bug: non-persistent Responses routes replay stale item ids #89330
• Related PR: fix: skip Responses item id replay without store #89128

Current main checked

• Latest upstream main: ed4c4afc0f6e6ce455bafcd3a2d4857fd1ebc778
• GitHub compare 03dec8...main: 03dec8bb3a00209780d3140ec3f10ad0eb069030 is the merge base and main is ahead, so the earlier fix is present in current main.

Affected path

This affects custom OpenAI Responses-compatible providers where the model configuration explicitly strips/does not support store, for example:

{
  api: "openai-responses",
  provider: "custom-openai-responses",
  baseUrl: "https://custom.example.com/v1",
  compat: { supportsStore: false }
}

In this path, the payload policy resolves to:

• explicitStore === undefined
• shouldStripStore === true
• no persistent Responses store is used

However, current main still uses:

const policyAllowsReplayIds = payloadPolicy.explicitStore !== false;

Because undefined !== false is true, prior Responses item ids can still be replayed for a storeless request.

Deterministic reproduction

A source-level reproduction calls buildOpenAIResponsesParams with:

• api: "openai-responses"
• provider: "custom-openai-responses"
• baseUrl: "https://custom.example.com/v1"
• compat: { supportsStore: false, supportsPromptCacheKey: false }
• prior assistant content containing replayable reasoning, message, and function_call item ids

Actual behavior on current main

main@ed4c4afc0f6e6ce455bafcd3a2d4857fd1ebc778 still replays previous Responses item ids:

{
  "sourceLabel": "latest upstream main",
  "sourceSha": "ed4c4afc0f6e6ce455bafcd3a2d4857fd1ebc778",
  "provider": "custom-openai-responses",
  "baseUrl": "https://custom.example.com/v1",
  "store": null,
  "hasAnyPriorReplayId": true,
  "safeForStorelessReplay": false,
  "replayedIds": [
    { "type": "message", "id": null, "call_id": null },
    { "type": "reasoning", "id": "rs_prior", "call_id": null },
    { "type": "message", "id": "msg_prior", "call_id": null },
    { "type": "function_call", "id": "fc_prior", "call_id": "call_abc" },
    { "type": "message", "id": null, "call_id": null }
  ]
}

Expected behavior

When Responses store is stripped or unsupported, previous Responses item ids should not be replayed. The stateless request may keep content needed for replay, but the stale store-backed ids should be omitted.

The updated fix branch produces:

{
  "sourceLabel": "updated fix branch",
  "sourceSha": "ce91ed58658c11c875055ee252c7e6f755cc7cba",
  "provider": "custom-openai-responses",
  "baseUrl": "https://custom.example.com/v1",
  "store": null,
  "hasAnyPriorReplayId": false,
  "safeForStorelessReplay": true,
  "replayedIds": [
    { "type": "message", "id": null, "call_id": null },
    { "type": "reasoning", "id": null, "call_id": null },
    { "type": "message", "id": null, "call_id": null },
    { "type": "function_call", "id": null, "call_id": "call_abc" },
    { "type": "message", "id": null, "call_id": null }
  ]
}

Why #89330 / 03dec8 did not cover this case

03dec8 covers cases where explicitStore is false, but this custom Responses-compatible path has:

explicitStore === undefined
shouldStripStore === true

So the current guard still permits replay:

payloadPolicy.explicitStore !== false // true when explicitStore is undefined

The missing condition is to also gate replay when shouldStripStore is true.

Suggested fix direction

Gate replay ids on shouldStripStore as well, for example:

const policyAllowsReplayIds =
  payloadPolicy.explicitStore !== false && !payloadPolicy.shouldStripStore;

And ensure the wrapper path passes replayResponsesItemIds: false when the payload policy strips store support.

Validation notes

The updated branch was rebased/merged onto latest upstream main and verified with a source-level reproduction. Focused Vitest runs were attempted locally, but the current environment SIGKILLed during test bundling after dependency setup; the deterministic source-level reproduction above is the direct evidence for the regression path.