One thing I'd like to discuss about this implementation:

The condition check

I copied the exact logic from defaultErrorHandler in error-handler.js:

if (!reply[kReplyHasStatusCode] || reply.statusCode === 200) {

However, I'm wondering if this condition might be slightly off semantically. If a user explicitly calls reply.code(200) before throwing an error, kReplyHasStatusCode would be true, but statusCode === 200 is also true, so the condition passes and we'd still override it.

Technically, if the user explicitly set a status code, we probably shouldn't override it regardless of the value. So a stricter check would be:

if (!reply[kReplyHasStatusCode]) {

That said, the current logic matches defaultErrorHandler's behavior, and the scenario of explicitly setting 200 then throwing an error is pretty rare in practice.

Should I:

1. Keep it as-is to match defaultErrorHandler behavior (current implementation)
2. Simplify to just !reply[kReplyHasStatusCode] (and potentially update defaultErrorHandler too for consistency)

Happy to go either way based on your preference!

Thanks for the review! I've addressed your feedback:

1. Extracted the repeated logic into a dedicated setErrorStatusCode function
2. Simplified the inject calls in tests using shorthand syntax

I initially tried adding the function to Reply.js as suggested, but it caused a circular dependency warning (reply.js → handle-request.js → reply.js). So I created a separate lib/error-status.js module instead, which follows the naming pattern of error-handler.js and error-serializer.js.

The extracted function also includes a null check (err &&) that was present in error-handler.js but missing in my original implementation - this makes the code more robust.