fix(test): assert the default Accept header on the parameters fetch - #182
Merged
Merged
Conversation
The release workflow fails on "Resource parameters can be retrieved":
AssertionError: expected last "spy" call to have been called with
[ 'http://localhost/books', …(1) ]
- "headers": {},
+ "headers": Headers {},
Two pull requests crossed. #179 added the assertion expecting a plain
"headers: {}", and #178 merged twenty seconds later made setHeaders() always
build a Headers instance carrying the default Accept. Both were green against
main as it stood when each ran, so neither CI saw the other.
Assert what the two changes together are meant to guarantee: the parameters
fetch targets the collection and carries the default Accept header. Comparing
against a Headers instance is not an option, it has no enumerable own
properties and the matcher reports "no visual difference" while failing.
Coverage Report
File CoverageNo changed files found. |
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 release workflow for v0.16.11 failed on
Run tests, so 0.16.11 was tagged but never published to npm.Cause
Two pull requests crossed, twenty seconds apart:
57499c5(#179)headers: {}9738687(#178)setHeaders()always return aHeadersinstance carrying the defaultAcceptBefore #178,
setHeaders()short-circuited on a falsyoptions.headersand returned{ ...options, headers: {} }with noAcceptat all, which is exactly the bug #178 set out to fix. #179 was written against that behaviour.Each run was green against
mainas it stood at the time, so neither CI saw the other.mainhas been red ever since.Fix
Assert what both changes together are meant to guarantee: the parameters fetch targets the collection, and it carries the default
Accept.Comparing against a
Headersinstance is not a workable alternative.Headersexposes no enumerable own properties, so the matcher reports "Compared values have no visual difference" while still failing.Verification
pnpm test33/33,pnpm typecheck,pnpm lintandpnpm format:checkall clean.setHeaders()makes it fail withexpected null to be 'application/ld+json', so it now guards Fix missing default Accept header when options is an empty object #178's fix rather than just accepting whatever is passed.