kamilogorek
commented
6 years ago They are indeed lost, as most of the information in frameworks are passed through prototypes and custom getter methods. Although, we still copy all the information that's directly attached to the request - https://github.com/getsentry/raven-node/blob/master/lib/client.js#L608-L609
I'm not sure if we want another config option right now, as we're in the process of writing next major version of our JS SDKs and every new option, will make it more complicated.
There are two things that I can propose. We can either add more options to be handpicked (if they are "somewhat" generic) or prior to catching the error in the middleware (which I assume you already do if you follow our docs), you can attach those properties directly to req object in the errorHandler, so that they'll be copied over - https://github.com/getsentry/raven-node/blob/master/lib/client.js#L551-L568
Do you want to request a feature or report a bug?
Feature request
Has someone had this problem before?
Similar to https://github.com/getsentry/raven-node/issues/360
What is the current behavior?
When using the Express middleware, Raven ignores all properties of the
requestobject except a handpicked set of properties. If therequestinformation has other properties relevant for the error report, they are lost*What is the expected behaviour?
Provide a configurable method that receives the original
requestand returns an object of custom properties that will be attached to the report, either as extras or tags.*There is currently a workaround: we can use the
parseUsermethod for this, but feels a bit hacky.I can make a PR for this change, but I first want to know what's the feeling about this. Is this a valid concern?
In my particular use case, we have a middleware that annotates the request object with some info extracted form the URL, plus some values from the environment. I'd like to send that info with the error report, but it is difficult to re-compute some of those values because the original value might have changed.