As the branch name suggests, the focus for this PR was to capture HTTP request and response details and include them in the Raygun payloads where relevant. I did this because I noticed one of the options is "ignoredFormFieldNames" which is related to the HTTP request section of the Raygun payload, and yet this sink no longer captures these details.
The way I have added this support is by replacing the Send(message) call with a Send(exception) call. In order to maintain all the functionality that this Sink currently has, we attach an event handler to the SendingMessage event on the Raygun client. This event is fired whenever a message is about to be sent to Raygun, and provides the message payload model for reading and mutating. In the event handler, most of the logic will read the UserCustomData (which is set to be the log properties) and then use those values to add/update various other parts of the message model.
This worked out very smoothly, apart from the timestamp which I maintained by introducing a new property key. This gets set before sending the exception, then gets read and removed from the properties list in the SendingMessage event handler.
The result of this has regained support for capturing HTTP request/response details, but also unlocks other features provided by Raygun4Net:
Stripping out wrapped exceptions - there is a configuration option for this already called "wrapperExceptions", but this feature was being bypassed due to sending a manually built message payload model. This strips away any unwanted outer exception and only sends the resulting inner exception(s). Unlike with Raygun4Net, this sink will not strip any default wrapper exception - so any undesired wrapper exceptions needs to be specified through this option.
Application version will automatically be picked up from the version of the entry assembly of the application.
Avoid accidentally sending the same exception instance multiple times. It's possible to setup logging in such a way that the same exception instance tries to be logged to Raygun multiple times - for example, you could have both Serilog and Raygun integrated, or hook into multiple ways to capture unhandled exceptions. Sending the same Exception instances to Raygun multiple times will use up Raygun customers monthly usage - so Raygun4Net automatically prevents this.
Offline exception report storage (for apps that can use isolated storage). When a crash report fails to be sent to Raygun e.g. internet connectivity issues, then they get stored to local storage to be sent another time.
Most of the RaygunSettings can now be used, a lot of which relate to capturing HTTP details.
As the branch name suggests, the focus for this PR was to capture HTTP request and response details and include them in the Raygun payloads where relevant. I did this because I noticed one of the options is "ignoredFormFieldNames" which is related to the HTTP request section of the Raygun payload, and yet this sink no longer captures these details.
The way I have added this support is by replacing the Send(message) call with a Send(exception) call. In order to maintain all the functionality that this Sink currently has, we attach an event handler to the SendingMessage event on the Raygun client. This event is fired whenever a message is about to be sent to Raygun, and provides the message payload model for reading and mutating. In the event handler, most of the logic will read the UserCustomData (which is set to be the log properties) and then use those values to add/update various other parts of the message model.
This worked out very smoothly, apart from the timestamp which I maintained by introducing a new property key. This gets set before sending the exception, then gets read and removed from the properties list in the SendingMessage event handler.
The result of this has regained support for capturing HTTP request/response details, but also unlocks other features provided by Raygun4Net:
Additionally, this PR resolves https://github.com/serilog/serilog-sinks-raygun/issues/31 by removing the null/whitespace check on the api key.