test: preserve Content-Type in stubFetch response clone on Deno 2.x#159
Merged
Conversation
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #159 +/- ##
=======================================
Coverage 96.95% 96.96%
=======================================
Files 39 39
Lines 1643 1648 +5
Branches 25 25
=======================================
+ Hits 1593 1598 +5
Misses 47 47
Partials 3 3 ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
zimeg
force-pushed
the
fix/response-clone-content-type-deno2
branch
from
July 1, 2026 14:18
b4e5b04 to
e1b67f5
Compare
On Deno 2.x, `Response.clone()` drops headers set from a plain object
literal (e.g. `{ "Content-Type": "application/json" }`), so `stubFetch`
returned a cloned response with a missing Content-Type. This surfaced as
a `test (v2.x)` failure in the Deno CI matrix, which — with the default
fail-fast — cancelled the v1.x and v1.46.2 jobs too.
Reconstruct the response from a fresh `Headers` copy so the stubbed
response preserves its headers regardless of how the caller built it, and
set `fail-fast: false` on the Deno test matrix so each version reports
independently.
Co-Authored-By: Claude <svc-devxp-claude@slack-corp.com>
zimeg
force-pushed
the
fix/response-clone-content-type-deno2
branch
from
July 1, 2026 14:18
e1b67f5 to
4b397eb
Compare
zimeg
marked this pull request as ready for review
July 1, 2026 14:19
Member
Author
zimeg
enabled auto-merge (squash)
July 1, 2026 14:19
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
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.
Summary
This pull request fixes a
test (v2.x)failure in the Deno CI matrix caused by aResponse.clone()behavior change on Deno 2.x.Response.clone()drops headers set from a plain object literal (e.g.{ "Content-Type": "application/json" }). Headers set via aHeadersinstance survive.stubFetchreturnedresponse.clone()directly, so a stubbed response built with plain-object headers lost itsContent-Type— breakingtesting/http_test.tsonv2.x(response.headers.get("Content-Type")returnednull).new Headers(response.headers)copy so the stub preserves headers regardless of how the caller built theResponse.fail-fast: falseon the Deno test matrix — thev2.xfailure was cancelling thev1.xandv1.46.2jobs, hiding that those versions actually passed.testing
deno task test— the full suite (fmt, lint, 37 tests) passes on Deno 2.x, wherestubFetch's "should replace global fetch with a stub" previously failed.v1.x,v1.46.2,v2.x) independently rather than cancelling siblings on first failure.Special notes
Root cause isolated with a minimal repro: a
Responsebuilt withheaders: { "Content-Type": "application/json" }returnsnullfor that header after.clone()on Deno 2.x, while the same built withnew Headers({...})preserves it.Requirements
deno task testafter making the changes.🤖 Generated with Claude Code