feat(errors): Added error handling hook for observability

[milkyontheblock]

No description provided.

[molty3000]

Review: Changes Requested

Overall a useful feature — the onError hook fills a real observability gap. But there are issues that should be addressed before merge.

Issues

1. Wrong TypeScript type for req parameter (index.d.ts line 62) — uses browser Request type instead of http.IncomingMessage
2. No res parameter — error hooks without response access can't set custom error responses, limiting observability integrations
3. Scope creep in package.json — pump dependency + devDependencies reordering unrelated to error handling

Warnings

• No tests for the new onError hook — 0 test coverage for the feature
• Empty PR description — no motivation, usage, or changelog
• Pre-existing test failure not addressed — (hooks) GET /users/on-request-error/info - 500 already fails on master

Suggestions

• Pass res as third parameter for richer integrations
• Make hook async-signalable (return value could suppress next(err))
• Document in README
• Add newline at EOF in demos/errors.js

See inline comments for details.

[molty3000]

Issue: No res parameter — The hook receives (err, req) but not res. Most observability integrations (Sentry, DataDog, NewRelic) benefit from response context — setting custom headers, logging status codes, or providing fallback error responses. Without res, users who want to return a custom error JSON body instead of the generic "Internal Server Error" can't do it here.

Consider adding res as a third parameter, or making this an async-compatible hook that can override the error response.

[molty3000]

Issue: Wrong TypeScript type for req — Request is a browser/Fetch API type. In Node.js, the correct type is http.IncomingMessage. This will cause TypeScript compilation errors for users.

Either use http.IncomingMessage or stay consistent with the other hooks and use Function (matching the pattern of onRequest?: Function, onResponse?: Function above).

[molty3000]

Issue: Return value ignored — The hook is fire-and-forget. Users who want to handle the error themselves (return a custom response, log and suppress, etc.) have no way to signal that.

Consider: if onError returns true, skip the next(err) call so the route can produce a custom error response.

[molty3000]

Scope creep — Adding pump as an explicit dependency and reordering devDependencies is unrelated to the error handling feature. These changes should be in a separate PR, or at minimum called out in the PR description. pump was already available as a transitive dependency — this is a cleanup, not part of the feature.

[molty3000]

Minor — Missing newline at end of file (\ No newline at end of file in the diff). POSIX convention.

[molty3000]

Additional finding: Linting violations in demos/errors.js

Ran npx standard (JavaScript Standard Style) on the PR's changed files. Two violations found:

Line	Rule	Current	Expected
demos/errors.js:15	space-before-function-paren	onError(err, req) {	onError (err, req) {
demos/errors.js:25	eol-last	Missing newline at EOF	POSIX trailing newline

index.js passes lint clean. These are quick fixes — run npx standard --fix demos/errors.js to auto-correct both.