fix: display the correct message when passing a bigint to res.status.

[Vedant224]

Fixes#6756

This PR adds type validation to res.sendStatus() to prevent uncaught TypeError when BigInt values are passed as status codes.

Problem:

• res.sendStatus(200n) caused uncaught "Do not know how to serialize a BigInt" error
• Error occurred when sendStatus() called this.status() which internally uses JSON.stringify()

Solution:

• Add type checking at the beginning of sendStatus() method
• Throw consistent TypeError: Invalid status code for non-number inputs
• Matches existing error handling patterns in Express

Changes:

• Add type validation in lib/response.js
• Add test case for BigInt input in test/res.sendStatus.js
• All existing tests pass (1239 passing)
• Follows existing error message format
• No linting errors

Testing:

npm test# All 1239 tests pass
npm run lint # No errors

[bjohansebas]

This looks good, although this will be released for version 6 since it would be a breaking change, and we should first release a warning in version 5. Could you create a new PR to add a deprecation message?

[Vedant224]

@bjohansebas I've created the deprecation warning PR as requested. I kept it targeting master since that shows my actual 2-file changes cleanly. When I tried changing the target to 5.x it showed 36 changes (difference between branches).

Should I leave it targeting master and you'll handle getting it into Express v5, or would you prefer a different approach for the branch targeting?

The deprecation warning PR is ready for review - it adds the deprecate() call for non-number values in sendStatus().

[krzysdz]

This looks good, although this will be released for version 6 since it would be a breaking change, and we should first release a warning in version 5. Could you create a new PR to add a deprecation message?

I don't think that it would be a breaking change - 5.x already includes validation that was added in #4212. This probably could be documented better, because it's mentioned only for res.status (both in migration guide and History.md), but the same PR modified res.sendStatus to use res.status in order to benefit from this new validation.

The problem with serialization occurs during creation of the validation error message (see #6756 (comment)).

[jonchurch]

We centralize our validation for status codes in the .status method which sendStatus relies on.

Any changes to the validation should happen there.

[jonchurch]

Also it's not an uncaught exception, we expect a throw for invalid status and it will be handled.

The enhancement would be the error message change, which makes this a very low prio change IMO.

[wesleytodd]

Leaving as a comment since @jonchurch has a blocking review. But once those are changed consider this a ✅ from me.

[wesleytodd]

Agreed with @jonchurch, move this to res.status, but throwing for BigInt is the right way to go.

[wesleytodd]

This test will need to move to res.status.js after the other change.

[Vedant224]

@jonchurch@wesleytodd I've updated the PR to address the feedback.
I moved the validation logic entirely to res.status, and res.sendStatus now calls that internally, so there are no duplicate checks.
I used typeof for the validation because standard string conversion turns 200n into "200", which makes the error message really confusing ("Invalid status code: 200"). By catching it early, we can show the actual issue ("Invalid status code: 200 (bigint)")..
As a side effect of using typeof, all invalid inputs (strings, null, objects) are now including their type in the error message (e.g., 200 (string) or null (object)).
All test cases are passing

[bjohansebas]

LGTM, thanks!

Good catch, team.