Repository navigation
fix: keep a Request's own headers in withUsageHeaders - #117
Merged
Merged
Conversation
When `withUsageHeaders` was called with a Request carrying its own
headers and no `init.headers`, it passed `init.headers` made of only
the usage headers. `fetch(request, { headers })` replaces the
Request's headers, so its `Authorization` and anything else were lost.
Start from the Request's headers when `init` brings none. When both
are given, `init.headers` still wins, as it does with `fetch`, and the
usage headers still win over either.
Nothing in the CLI passes a Request today (the OAuth provider calls it
with a URL and options), so this was latent.
doist-release-bot Bot
added a commit
that referenced
this pull request
Nov 11, 2026
## [4.1.3](v4.1.2...v4.1.3) (2026-11-11) ### Bug Fixes * keep a Request's own headers in withUsageHeaders ([#117](#117)) ([d3eeac0](d3eeac0))
Contributor
|
🎉 This PR is included in version 4.1.3 🎉 The release is available on: Your semantic-release bot 📦🚀 |
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
withUsageHeadersbuiltinit.headersfrominit.headersplus the usage headers only. When it was called with aRequestthat carries its own headers and noinit.headers,fetch(request, { headers })replaced the Request's headers with just the usage headers, so itsAuthorization(and anything else on it) was dropped.The wrapper now starts from the Request's own headers when
initbrings none. When both are given,init.headersstill wins, as it does withfetch, and the usage headers still win over either. This mirrors the same fix in the Automations CLI'sfetchWithUsageHeaders.Nothing in comms-cli passes a
Requesttoday (the OAuth provider calls the wrapped fetch with a URL string and options), so the bug was latent; this keeps the wrapper's contract true for any future caller.Tests
New
withUsageHeaderscases insrc/lib/usage-tracking.test.ts. The fakefetchbuildsnew Request(input, init)from its arguments, as the real one does, so the assertions are on the headers the request would actually go out with.Authorization, passed with noinit, keeps it alongside the usage headers. Failed before the fix (authorizationmissing), passes after.init.headers,init.headerswins and a Request-only header is gone. Fails if the fix is changed to prefer the Request's headers.User-Agent).init.headerson a URL input are kept alongside the usage headers.npm run verifypasses.