chore(http-recorder): remove content-matching dispatch mode#26792
Merged
Conversation
Sequential cursor replay is now the only behavior. The previous default
("match") returned the first recorded response for any subsequent
byte-identical request, silently passing cache-hit, retry, and polling
tests during RECORD=true (where the real network produced distinct
responses) and breaking them on replay.
Audit found zero explicit "match" callers across the repo. Re-recording
after a test reorders requests is the right discipline; the silent
record/replay divergence is not worth the rare reorder-without-rerecord
convenience.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Why
The
dispatch: "match"default in@opencode-ai/http-recorderis a silent record/replay divergence footgun. For tests that send the same request shape twice (cache-hit tests, retry tests, polling loops), the real network duringRECORD=trueproduces two distinct responses — but on replay the content-matcher returns the first recorded response for both calls. Assertions that verify state change pass during recording and quietly fail later.Audit of the repo turned up zero explicit
"match"callers — every recorded test either setdispatch: "sequential"explicitly or accidentally relied on the buggy default. The "reorder a test without re-recording" convenience the mode was designed for is rare; the silent divergence cost is real.What changed
dispatch?: "match" | "sequential"option fromRecordReplayOptions.selectMatchandmismatchDetailfromsrc/matching.ts.RequestMatcher,defaultMatcher,canonicalSnapshot,requestDiff, andselectSequentialstay — sequential replay still validates each interaction's request against the incoming request.{ dispatch: "sequential" }overrides in the package's own tests, removed the test that asserted the deleted content-matching behavior, and removed the test that documented the buggy "same request twice returns first match" outcome.packages/http-recorder/README.mdandpackages/llm/AGENTS.mdto describe the single behavior.No production code outside
packages/http-recorder/srcand the docs inpackages/llm/AGENTS.mdwas touched. No downstream provider test passeddispatchon this branch, so no test files inpackages/llm/test/providerneeded changes.Migration
If you reorder requests in a test, re-record the cassette (delete the JSON fixture and run with
RECORD=true). The cassette JSON format is unchanged.Test plan
bun run --cwd packages/http-recorder test— 15 pass, 0 failbun run --cwd packages/http-recorder typecheck— cleanbun run --cwd packages/llm test— 171 pass, 31 skip, 0 failbun run --cwd packages/llm typecheck— clean