Errors thrown in the 'request' hook are silently ignored
Nobody has claimed this yet.
- 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
- 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
});
});
- Start the Nitro dev server (
npx nitropack dev). - 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
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- 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