-
-
Notifications
You must be signed in to change notification settings - Fork 210
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Finish unfinished Spans on Transaction completion #1296
Conversation
src/Sentry/SentryEventExtensions.cs
Outdated
=> @event.Level >= SentryLevel.Error || | ||
@event.Exception is not null || | ||
@event.SentryExceptions?.Any() == true; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is there an IntenralExceptions
instead? Otherwise it'll instantiate a list on the property getter IIRC
=> @event.Level >= SentryLevel.Error || | |
@event.Exception is not null || | |
@event.SentryExceptions?.Any() == true; | |
=> @event.Level >= SentryLevel.Error | |
|| @event.Exception is not null | |
|| @event.InternalSentryExceptions?.Any() == true; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There's no InternalSentryExceptions
.
We could use @event.HasException but that's basically the same code
sentry-dotnet/src/Sentry/SentryEvent.cs
Line 167 in 997a310
internal bool HasException => Exception is not null || SentryExceptions?.Any() == true; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
sentry-dotnet/src/Sentry/SentryEvent.cs
Lines 75 to 84 in 41a9ab9
internal SentryValues<SentryException>? SentryExceptionValues { get; set; } | |
/// <summary> | |
/// The Sentry Exception interface. | |
/// </summary> | |
public IEnumerable<SentryException>? SentryExceptions | |
{ | |
get => SentryExceptionValues?.Values ?? Enumerable.Empty<SentryException>(); | |
set => SentryExceptionValues = value != null ? new SentryValues<SentryException>(value) : null; | |
} |
test/Sentry.Tests/HubTests.cs
Outdated
Assert.Equal(_fixture.TraceId, @event.Contexts.Trace.TraceId); | ||
Assert.Equal(_fixture.ParentId, @event.Contexts.Trace.ParentSpanId); | ||
Assert.True(span.IsFinished); | ||
Assert.Equal(SpanStatus.UnknownError, span.Status); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This makes me realize that we're diverging here. Other SDKs are defaulting to Ok
when no status is set. @marandaneto recently talked about this on another repo. He might be able to chime in here
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I have to agree that it was the expected result that I was expecting by calling Finish()
but instead I got UnknownError
.
I could make a separate PR to alter the default Finish status and then update this PR.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
for HTTP spans -> getsentry/develop#307 (comment)
if its a UI transaction, default to ok
unless there's an exception (then INTERNAL_ERROR).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
if there's no status at all, relay (ingestion) or UI not sure defaults to unknown
I'll fix the DiagnosticSource integration for SQLClient on another PR since once merged this PR will make the SQL Client integration generate some noise (for instance, multiple connections spans for the same connection id). |
Codecov Report
@@ Coverage Diff @@
## main #1296 +/- ##
==========================================
- Coverage 82.60% 82.58% -0.03%
==========================================
Files 213 213
Lines 7116 7119 +3
Branches 1401 1402 +1
==========================================
+ Hits 5878 5879 +1
- Misses 803 807 +4
+ Partials 435 433 -2
Continue to review full report at Codecov.
|
…thub.com/getsentry/sentry-dotnet into fix/message-only-errors-not-closing-span
test/Sentry.Tests/HubTests.cs
Outdated
[Theory] | ||
[InlineData(SentryLevel.Error)] | ||
[InlineData(SentryLevel.Fatal)] | ||
public void CaptureEvent_ErroredMessageWithoutException_ClosesCurrentSpanAsInternalError(SentryLevel level) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure we should close the span. This will affect the end timestamp by setting the end of the span to the time the error happened, even if the span was still running for a long time after.
Capturing the even should include the trace information, which will help Sentry show in the span that there was a related error. The time the span finishes shouldn't be affected. I believe neither should the status. Say there was a try/catch. The user logged the error, but handled it, and had a retry logic that then succeeded. The overall span was OK, it took longer because it did more things than it needed if it had succeeded in the first place though.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Since spans are getting closed once the Transaction is concluded, I have removed the special code that was closing the spans if none of them were sampled.
…thub.com/getsentry/sentry-dotnet into fix/message-only-errors-not-closing-span
so this was a breaking change since it removed |
Also, consider as Errored Events with Level greater or equal to Error.