Problem

sanitizeStatusCode can return NaN, defeating its own documented purpose ("Make sure the status code is a valid HTTP status code"):

sanitizeStatusCode("abc") // => NaN

+"abc" is NaN, and both NaN < 100 and NaN > 599 evaluate to false, so the range guard lets NaN through.

This is reachable through HTTPError. Its status is derived from an arbitrary cause:

const status = sanitizeStatusCode(
  (details as ErrorBody)?.status ||
    (details as ErrorInput)?.statusCode ||
    (details?.cause as ErrorBody)?.status ||
    (details?.cause as ErrorInput)?.statusCode,
  500,
);

cause is any caught error, so a non-numeric statusCode/status on it (e.g. a wrapped library error) yields an HTTPError with status: NaN — an invalid HTTP response.

Fix

Rewrite the range guard as a positive check. NaN >= 100 is false, so NaN now correctly falls back to the default:

return statusCode >= 100 && statusCode <= 599 ? statusCode : defaultStatusCode;

Strictly behaviour-preserving for every numeric input in/out of range; only the previously-undefined NaN path changes (now returns the default). The ternary is also smaller than the prior two-statement if/return, so the defineHandler bundle-size budget test stays green.

Tests

Added test/unit/sanitize.test.ts covering valid pass-through, out-of-range fallback, non-numeric-string fallback, and the HTTPError-from-non-numeric-cause regression. Full suite green (1154 passed), tsc 0 errors, oxlint + oxfmt clean.

Summary by CodeRabbit

• Bug Fixes

  • Improved status code validation to properly reject non-numeric and out-of-range values, ensuring invalid codes fall back to sensible defaults

• Tests

  • Added unit test coverage for status code validation and error handling with invalid inputs