microsoft
trackException only works with Error type, not derived types
The current implementation validates that the exception is instanceof Error and then only copies a couple of key details from the Error object onto an ExceptionDetails object, which loses any custom metadata that the app might have wanted to log as part of the exception.
An acceptable compromise is that any other fields in the exception object be made part of the envelope properties member.
https://github.com/microsoft/ApplicationInsights-node.js/blob/b797bc9678fcf0c113d8c9ab154557c15308b5c1/Library/EnvelopeFactory.ts#L169-L171
@asklar the SDK handles most common scenario, we expose APIs for any specific scenarios that customers may have, trackException accepts properties map that can be used to store any custom metadata, automatically adding extra properties to the exception event could cause issues with other customers increasing their telemetry size without benefit.
I can see that however there is no indication to the developer that their data is going to be dropped on the floor. Data loss is worse than having added data with no benefit IMO.
Either support anything extending Error, or crash if type is not exactly Error, and also document that Error is the only supported class for exceptions.
As a customer of AI, I don't expect the behavior of just silently dropping my data. FWIW I spent way too much time debugging into AI to figure this out, so addressing this by either crashing/asserting and adding documentation would be a good and necessary step.
What kind of Errors do you want to track?, if you extend Error class, the SDK must be able to handle it correctly using "instanceof", let me know if this is not the case, what kind of extra properties are you interested in? are you suggesting to iterate all properties in the object and add them in the properties field in the telemetry?, like you said data being dropped is an issue but also the possibility of increasing the event size and increasing customer costs, this is potentially something that could be handled with an extra configuration but will like to understand the scenario better.