fix/DF-531: Error stack traces #1114
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.



This should fix missing stack traces when an unhandled exception is encountered in a route handler.
More info
Hi all 👋
I'm looking for a way to capture and log stack traces when an unhandled exception is encountered in a route.
I have a generic onPreResponse handler for error logging that looks something like:
If I have a route that generates an unhandled error e.g.
The
response.stackinonPreResponseis always undefined.Stepping through the code it is because of this line in toolkit.js uses Boom.badImplementation which is stripping out the stack here in Hoek.clone
Is this by design? Has anyone overcome this and found a way to access the err.stack in an onPreResponse for unhandled system errors?
TIA
djs — 11:25 AM
Hoek is stripping it here when cloning the error, it gets the descriptor with key "stack" and redefines the property on the cloned error Object.defineProperty(newObj, key, descriptor) but the descriptor value is lost
djs — 12:16 PM
Looking at the most recent version of Hoek (11.0.7) it looks like stack now gets special handling (in node 21+). If I force Boom to use Hoek version 11.0.7, I see a stack trace in onPreResponse.
Latest Boom uses Hoek@^11.0.2.
Ok, I've now just seen this issue.
Given hapijs/hoek#390 is now merged, can we get a new version of Boom published? Or is it awaiting this?
djs — 1:12 PM
Node was installing [email protected] for boom. I fixed this by adding an explicit dependency to [email protected] in my package.json.