fix: stop dropping command and runtime headers when the client has none - #15
Merged
Merged
Conversation
0f03f56 moved the `if (!headers) return {}` guard from the old resolveHeaders() helper — which received the already-merged object — onto this.#headers alone. A client constructed without config headers therefore short-circuited the merge and sent no headers at all, losing command.headers, runtimeOptions.headers, and json()'s own accept/content-type defaults. Every request with a body arrived unparsed. The same refactor also flipped precedence, spreading client headers over command headers instead of under them. Both are restored to the pre-14.0.0 order: client < command < runtime. Covered by four tests, three of which fail without this change. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
maxholman
force-pushed
the
fix/resolve-headers-drops-headers
branch
from
September 3, 2026 03:59
dd80b0f to
051cec9
Compare
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.
The regression
Reported downstream: 5 tests in
services/listing/test/app.test.tsfail against@block65/rest-client@14.0.0— every one that sends a body.RestServiceClient.#resolveHeadersbails before merging anything:A client constructed without
config.headerssends no headers at all — including theacceptandcontent-typethatjson()sets on every call. That is why only body-sending requests fail: they arrive withoutcontent-type: application/jsonand the server never parses them.How it happened
0f03f56 inlined the old
resolveHeaders()helper fromlib/common.ts. That helper'sif (!headers) return {}guard was correct there, because it received the already-merged object:The refactor carried the guard along but re-pointed it at
this.#headersalone, so it now short-circuits the merge rather than an empty result.The same refactor also flipped precedence — client headers were spread over command headers instead of under them, so a command could no longer override a client default.
The fix
Resolve
this.#headers ?? {}and merge unconditionally, restoring the pre-14.0.0 order: client < command < runtime.Why the suite missed it
Every test in
describe("Client")shares one client constructed withheaders, sothis.#headerswas never falsy and the early return never ran. No test constructed a bare client, and no command carried a header colliding with a client one, so the precedence flip was invisible too.Four tests added: a bare-client block (json() defaults; command + runtime headers) and two precedence tests. Three fail without the fix — the fourth (runtime over command) passed either way, since the runtime spread was last in both versions.
Checks
tscclean,oxfmt --checkclean,oxlintunchanged (same 2 pre-existing warnings), 41/41 tests pass.Note
14.0.0 is published, so this needs a 14.0.1 once merged.
🤖 Generated with Claude Code