Skip to content

fix(node): keep req.headers live and consistent across _request materialization#265

Merged
pi0 merged 1 commit into
mainfrom
fix/node-req-headers-mutate
Jul 17, 2026
Merged

fix(node): keep req.headers live and consistent across _request materialization#265
pi0 merged 1 commit into
mainfrom
fix/node-req-headers-mutate

Conversation

@pi0x

@pi0x pi0x commented Jul 17, 2026

Copy link
Copy Markdown
Contributor

Resolves #245

Problem

On the Node adapter, once the native (undici) Request materializes — via req._request, clone(), formData()/blob()/bytes()/arrayBuffer(), or any lazily-inherited native property — get headers() switched from the NodeRequestHeaders wrapper to #request.headers. A reference taken earlier became detached: req.headers !== h, and mutations through h were silently lost. The approach tried in #243 (keep the wrapper canonical forever) fixed identity but froze _request.headers / clone() at a materialization-time snapshot, so it was reverted (1754b02).

Fix

Instead of swapping which object the getter returns, swap the wrapper's backing store. NodeRequestHeaders already fronts a lazily-built native Headers; at materialization it now _adopts the native request's Headers and becomes a pure facade over it. From then on there is a single mutable header store, so with no dual-write bookkeeping:

  • header references taken at any point stay live, and req.headers identity is stable forever,
  • mutations through req.headers are visible in _request.headers, clone(), and formData()'s content-type sniff,
  • mutations made directly on _request.headers are visible through req.headers (which one-way write-through could never give).

The untouched-headers hot path is unchanged; requests whose headers were accessed pay one extra branch + delegated call per header op after materialization.

Semantics note

After materialization the single store is the native request's Headers, which carries the fetch spec's "request" guard: forbidden-header mutations (e.g. set("host", …)) are silently filtered where the pre-materialization wrapper allowed them. This moves toward spec behavior and only applies once a native view exists.

Tests

Full suite: 1041 passed, lint + typecheck clean.

🤖 Generated with Claude Code

…ialization

Once the native Request materialized, `get headers()` switched to
`#request.headers`, detaching any previously-taken reference: mutations
through the old reference were silently lost. Instead of swapping which
object the getter returns, swap the wrapper's backing store: after
materialization `NodeRequestHeaders` adopts the native request's Headers
and becomes a pure facade over that single mutable store. Early
references stay live, `req.headers` identity is stable, and mutations
through either view are visible in both `req.headers` and
`_request.headers` / `clone()` / `formData()`.

Resolves #245

Co-Authored-By: Claude Fable 5 <[email protected]>
@pi0x
pi0x requested a review from pi0 as a code owner July 17, 2026 10:23
@coderabbitai

coderabbitai Bot commented Jul 17, 2026

Copy link
Copy Markdown

Warning

Review limit reached

@pi0x, you've reached your PR review limit, so we couldn't start this review.

Next review available in: 23 minutes

Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available.
You're only billed for reviews past your plan's rate limits ($0.25/file).

How can I continue?

After more reviews become available, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews.

How do review limits work?

CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability.

For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window.

Please refer docs for additional details.

Review details
⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

Run ID: a32144a6-964e-4a63-81b3-d0fe1c39ecde

📥 Commits

Reviewing files that changed from the base of the PR and between 8e4e073 and 380bd23.

📒 Files selected for processing (3)
  • src/adapters/_node/headers.ts
  • src/adapters/_node/request.ts
  • test/node-adapters.test.ts
✨ Finishing Touches
🧪 Generate unit tests (beta)
  • Create PR with unit tests
  • Commit unit tests in branch fix/node-req-headers-mutate

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

Comment @coderabbitai help to get the list of available commands.

@pkg-pr-new

pkg-pr-new Bot commented Jul 17, 2026

Copy link
Copy Markdown

Open in StackBlitz

npm i https://pkg.pr.new/srvx@265

commit: 380bd23

@pi0
pi0 merged commit dfb640a into main Jul 17, 2026
15 checks passed
@pi0
pi0 deleted the fix/node-req-headers-mutate branch July 17, 2026 10:25
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Node: req.headers identity and mutation visibility across _request materialization

2 participants