Log score uploader errors to sentry #217
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.
Before you open the diff, a few paragraphs of explanation.
For ASP.NET Core apps, there appear to be three disparate pathways to getting events onto sentry.
The first, and most direct one, is directly calling
SentrySdk.CaptureException()
. Generally does what you'd expect it to.The second is via
IWebHostBuilder.UseSentry()
. This is an ASP.NET-ism that works by injecting a sentry-provided middleware into the request handling stack. Thus, all requests that fail due to a thrown exception will be reported to sentry, as the middleware will catch the error, log it, and throw it back up to the rest of the ASP.NET stack to handle.However, note that this does not apply to background workers, as they are generally outside of this entire flow. Even if we weren't hand-rolling them via singletons instantiated in
Startup
, and instead usingIHostedService
/BackgroundService
which is the most correct ASP.NET-ism for that, for a proper persistent background service you can't throw exceptions because you'd kill both the background service, and the entire server with it.Therefore, the third method, and the one officially recommended by the sentry team for background worker use cases is to use sentry's extension of
Sentry.Extensions.Logging
. Doing this will middleman all log calls toMicrosoft.Extensions.Logging
and push all errors (and warnings too, I believe) to sentry.In the context of all of the above, #215 becomes doubly relevant; however, because that change requires more infra preparations and we probably want sentry logging on the replay upload process now, this is the minimal required change to make that happen.
A side effect of this change is that the replay upload errors - which would be printed to stdout via
Console.WriteLine()
- will still be printed there, but using ASP.NET's default logging format, which is a little more... talkative, as the example below shows:Additionally, note that we have two other background workers like
ScoreUploader
, and they are:MetadataBroadcaster
andBuildUserCountUpdater
. I don't consider them anywhere as key as replay upload, therefore they are left as they are until we can get the full logging unification changes in.Preview of how this looks from a private testing sentry instance I set up