nitrojs / nitrojs/nitro

Errors thrown in the 'request' hook are silently ignored

Open
#3,873 2 comments 1 reaction 0 assignees View on GitHub

Nobody has claimed this yet.

v2
Dominant language
TypeScript
Stars
11.2k
Forks
899
Avg merge
2d 24m
Merged PRs (30d)
40

Description

Hello!

When registering a handler for the 'request' runtime hook in a Nitro plugin, any errors thrown (synchronously or asynchronously) within the handler are caught internally and silently ignored. The error is neither logged (in development or production) nor does it propagate to fail the request or trigger the 'error' hook. As a result, the request continues processing as normal, which can lead to unexpected behavior and hard-to-debug issues.

This makes the 'request' hook unreliable for scenarios where an error should abort the request early (e.g., validation failures, authentication checks, or critical setup).

Steps to Reproduce

  1. Create a Nitro plugin (e.g., plugins/error.ts):
export default defineNitroPlugin(nitroApp => {
  nitroApp.hooks.hook('request', event => {
    throw new Error('OOPS!'); // This error is silently swallowed
  });
});
  1. Start the Nitro dev server (npx nitropack dev).
  2. Make any request to the server.

Expected Behavior

The error should:

  • Be logged to the console (definitely)
  • Cause the request to fail with a 500 response (not clear)

Alternatively, clear documentation warning that throwing errors in 'request' (and possibly other hooks) has no effect.

Actual Behavior
  • No error is logged.
  • No 500 response is sent.
  • The request proceeds normally and succeeds (or follows the normal route handling).

This issue can hide critical bugs in production if developers assume throwing in a 'request' hook will fail the request. Suggestion: Either change to propagate errors (with proper handling) or explicitly document the silent swallow behavior for specific hooks like 'request'.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Reproduce the behavior with plugins/error.ts using npx nitropack dev, then trace Nitro's request-hook dispatch and error handling. Determine the intended behavior for synchronous and asynchronous errors, and verify that the chosen propagation or documentation outcome covers the reported logging and request-response cases.

Written by the indexing model from the issue text.

Assessment

Tech stack
typescript
Domain
backend
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
42/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.