fix: incorrectly constructed responses for 204 status codes

[sparten11740]

When returning status(204) or status(204, null), the actual response gets constructed with an empty string instead of null. This throws an error in a variety of environments/runtimes (e.g. Vercel/Cloudflare). Instead we should construct the response passing in null as first param.

Fixes elysiajs/elysia#1277 for the node adapter

Vercel Error

Cloudflare Error

Constructing a Response with a null body status (204) and a non-null, zero-length body. This is technically incorrect, and we recommend you update your code to explicitly pass in a null body, e.g. new Response(null, { status: 204, ... }). (We continue to allow the zero-length body behavior because it was previously the only way to construct a Response with a null body status. This behavior may change in the future.)

I tested that this fixes the issue by deploying our app with a forked version of @elysiajs/node

Summary by CodeRabbit

• Bug Fixes
  • Corrected response handling to properly return null for undefined responses instead of empty strings, ensuring consistent behavior across the application.

[coderabbitai]

Walkthrough

The mapResponse function in src/handle.ts was modified to return a null body instead of an empty string body when handling undefined responses. This ensures compliance with HTTP standards for status codes like 204 (No Content) that must not carry a body.

Changes

Cohort / File(s)	Change Summary
Response body handling src/handle.ts	Modified undefined response case to return new Response(null, set) instead of new Response('', set), changing the body payload from empty string to null for falsy responses

Estimated code review effort

🎯 1 (Trivial) | ⏱️ ~3 minutes

• Specific area requiring attention: Verify that changing from empty string to null body doesn't break existing tests or edge cases related to response serialization, particularly for status codes that forbid bodies (204, 205, 304).

Possibly related issues

• #1277: This PR directly resolves the Cloudflare workers compatibility issue where 204 (No Content) responses with empty string bodies were being rejected. The change from empty string to null body aligns with HTTP specification requirements and Cloudflare's expectations for no-content status codes.

Poem

🐰 A rabbit hops through response streams,
Trading strings for null so clean,
No content? No body here!
Cloudflare cheers—the fix is clear,
204 now works like dreams ✨

Pre-merge checks and finishing touches

❌ Failed checks (1 warning, 1 inconclusive)

Check name	Status	Explanation	Resolution
Docstring Coverage	⚠️ Warning	Docstring coverage is 0.00% which is insufficient. The required threshold is 80.00%.	You can run @coderabbitai generate docstrings to improve docstring coverage.
Linked Issues Check	❓ Inconclusive	The PR successfully addresses the primary coding requirement from issue #1277 by modifying the response body construction logic in src/handle.ts to pass null instead of an empty string for 204 responses, which directly resolves the Cloudflare error described in the issue. However, the linked issue explicitly requests an additional coding-related requirement—updating type declarations so that status(204) can be called without requiring a second parameter—and the raw_summary indicates no alterations to exported or public entity declarations were made, leaving this requirement unaddressed.	To fully satisfy the linked issue requirements, the PR should be updated to include type declaration changes that allow status(204) to be called without requiring a second parameter. Clarification is needed on whether the type update is considered a mandatory requirement or an optional enhancement for this PR.

✅ Passed checks (3 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title Check	✅ Passed	The PR title "fix: incorrectly constructed responses for 204 status codes" directly reflects the primary change shown in the raw_summary, which involves modifying how response bodies are constructed when handling falsy responses—specifically changing from returning an empty string body to returning a null body for 204 status codes. The title is specific, clear, and accurately conveys the main objective of the changeset without unnecessary verbosity.
Out of Scope Changes Check	✅ Passed	The code changes in src/handle.ts are entirely focused on fixing the response body construction for 204 status codes by modifying the undefined-case behavior to pass null instead of an empty string, which directly aligns with addressing issue #1277. No extraneous changes or modifications unrelated to the stated objective of fixing incorrectly constructed 204 responses are evident in the provided summary.

✨ Finishing touches

• 📝 Generate docstrings

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment

---

📜 Recent review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between fbbe577 and f6faff4.

📒 Files selected for processing (1)

• src/handle.ts (1 hunks)

🔇 Additional comments (1)

src/handle.ts (1)

117-120: Fix at line 118 is correct; mapEarlyResponse design appears intentional but warrants verification.

The change from empty string to null body correctly addresses 204 No Content handling in the main response path. The mapEarlyResponse function's behavior of returning undefined for null/undefined responses appears intentional—returning undefined signals "no early response, continue to main handler," which then processes with the corrected status handling at line 118.

However, without access to test cases or architecture documentation, the early-response pattern cannot be definitively validated. Verify that 204 responses through early-response contexts (hooks/middleware) flow correctly to the main handler where the fix applies.

---

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

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}