fix: preserve Foundry Responses reasoning replay ids#91118
Conversation
|
Pre-land proof for this branch:
Live API proof gap: Molty 1Password metadata search found no available microsoft-foundry / Foundry / Azure OpenAI credential item, so I could not make a live Foundry call. The code path is still high-certainty: issue #91033 includes direct Foundry API proof that encrypted reasoning replay succeeds with the original reasoning item id and fails when OpenClaw drops that id. |
|
ClawSweeper status: review started. I am starting a fresh review of this pull request: fix: preserve Foundry Responses reasoning replay ids This is item 1/1 in the current shard. Shard 0/1. This placeholder means the worker is alive and reading the current context. I will edit this same comment with the actual review when the claws are done clicking. Crustacean status: shell secured, claws on keyboard, evidence pebbles being sorted. |
1 participant
Summary
Fixes #91033.
Verification
node scripts/run-vitest.mjs extensions/microsoft-foundry/index.test.ts src/llm/providers/openai-responses-shared.test.tspnpm lint:extensionspnpm lint:corepnpm check:test-typespnpm tsgo:extensionspnpm exec oxfmt --check --threads=1 extensions/microsoft-foundry/provider.ts extensions/microsoft-foundry/index.test.ts src/llm/providers/openai-responses-shared.test.tsgit diff --check/Users/steipete/Projects/agent-scripts/skills/autoreview/scripts/autoreview --mode local-> clean, no accepted/actionable findingsLive API Proof
Molty 1Password metadata search found no available microsoft-foundry / Foundry / Azure OpenAI credential item, so I could not run a live Foundry request. The fix follows the issue's direct API proof: Foundry accepts encrypted reasoning replay when the original reasoning item id is present and rejects the same replay when the encrypted content is sent without that id.