test(browser): add sendBeacon Content-Type test coverage#3317
Merged
dustinbyrne merged 1 commit intomainfrom Apr 1, 2026
Merged
test(browser): add sendBeacon Content-Type test coverage#3317dustinbyrne merged 1 commit intomainfrom
dustinbyrne merged 1 commit intomainfrom
Conversation
Follow-up from #3297 review discussion. Adds: - blob.type assertions to existing JSON and Base64 sendBeacon tests (only gzip was previously checked) - Test verifying sendBeacon is NOT called when body is undefined - Parameterized regression test covering all compression modes, asserting the body is always a Blob with the correct Content-Type These tests would have caught the bug fixed in #3297, where sendBeacon received a raw ArrayBuffer (no Content-Type) instead of a Blob, breaking proxies/WAFs/CDNs that require Content-Type.
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
Contributor
📝 No Changeset FoundThis PR doesn't include a changeset. A changeset (and the release label) is required to release a new version. How to add a changesetRun this command and follow the prompts: pnpm changesetRemember: Never use |
Contributor
Prompt To Fix All With AIThis is a comment left during a code review.
Path: packages/browser/src/__tests__/request.test.ts
Line: 458
Comment:
**Redundant `blob.type` assertions**
The `blob.type` assertions added here (line 458), at line 484, and the pre-existing one at line 510 are now fully covered by the parameterized regression test (`always sends a Blob with correct Content-Type for %s`) that was added in the same PR. This duplicates the same assertion for the same three compression modes in two places, violating the OnceAndOnlyOnce rule.
Consider removing the `blob.type` lines from the three individual tests and letting the parameterized test be the single canonical check for this property:
```suggestion
```
(i.e. drop line 458 entirely — same applies to line 484 and the pre-existing `expect(blob.type).toBe('text/plain')` at line 510)
How can I resolve this? If you propose a fix, please make it concise.Reviews (1): Last reviewed commit: "test(browser): add sendBeacon Content-Ty..." | Re-trigger Greptile |
Contributor
Contributor
|
Size Change: 0 B Total Size: 6.65 MB ℹ️ View Unchanged
|
marandaneto
approved these changes
Apr 1, 2026
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.
Problem
Follow-up from #3297 review discussion where I noted:
The existing sendBeacon tests did not fully assert that the body is always a
Blobwith the correcttype(which the browser uses asContent-Type). This gap allowed the bug fixed in #3297 to ship undetected.Changes
packages/browser/src/__tests__/request.test.ts:blob.typeassertions to the existing JSON (application/json) and Base64 (application/x-www-form-urlencoded) sendBeacon tests — previously only the gzip test checked this.sendBeaconis not called when body isundefined(covers the early return guard added in fix(browser): wrap sendBeacon body in Blob to ensure Content-Type header is set #3297).always sends a Blob with correct Content-Type for %s) covering all three compression modes (none, base64, gzip), asserting the body is always aBlobinstance with the expectedContent-Type.Verified: all 3 new tests fail with the pre-fix code and catch the exact bug that #3297 fixed (gzip body sent as raw
ArrayBuffer→ noContent-Typeheader).Release info Sub-libraries affected
Libraries affected
Test-only change, no library version bump needed.
Checklist