Skip to content
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

Merged
merged 22 commits into from
Nov 8, 2021

Conversation

lucas-zimerman
Copy link
Collaborator

@lucas-zimerman lucas-zimerman commented Nov 2, 2021

Also, consider as Errored Events with Level greater or equal to Error.

@lucas-zimerman lucas-zimerman added the Bug Something isn't working label Nov 2, 2021
src/Sentry/SentryEventExtensions.cs Outdated Show resolved Hide resolved
Comment on lines 11 to 13
=> @event.Level >= SentryLevel.Error ||
@event.Exception is not null ||
@event.SentryExceptions?.Any() == true;
Copy link
Member

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

Suggested change
=> @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;

Copy link
Collaborator Author

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

internal bool HasException => Exception is not null || SentryExceptions?.Any() == true;

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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 Show resolved Hide resolved
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);
Copy link
Member

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

Copy link
Collaborator Author

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.

Copy link
Contributor

@marandaneto marandaneto Nov 5, 2021

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).

Copy link
Contributor

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

test/Sentry.Tests/HubTests.cs Outdated Show resolved Hide resolved
src/Sentry/Internal/Hub.cs Outdated Show resolved Hide resolved
@lucas-zimerman lucas-zimerman changed the title Fix Session not being closed on errored event without exception (DONT MERGE) Finish unfinished Spans on Transaction completion (DONT MERGE) Nov 4, 2021
@lucas-zimerman
Copy link
Collaborator Author

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).

@lucas-zimerman lucas-zimerman changed the title Finish unfinished Spans on Transaction completion (DONT MERGE) Finish unfinished Spans on Transaction completion Nov 4, 2021
@codecov-commenter
Copy link

codecov-commenter commented Nov 4, 2021

Codecov Report

Merging #1296 (bb0063e) into main (78aa050) will decrease coverage by 0.02%.
The diff coverage is 57.14%.

Impacted file tree graph

@@            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     
Impacted Files Coverage Δ
src/Sentry/Internal/Hub.cs 73.26% <ø> (-0.29%) ⬇️
src/Sentry/SentryEventExtensions.cs 0.00% <0.00%> (ø)
src/Sentry/Transaction.cs 82.55% <100.00%> (ø)
src/Sentry/TransactionTracer.cs 94.44% <100.00%> (+0.19%) ⬆️
src/Sentry/ScopeExtensions.cs 70.00% <0.00%> (ø)

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 78aa050...bb0063e. Read the comment docs.

@lucas-zimerman lucas-zimerman marked this pull request as ready for review November 5, 2021 14:23
[Theory]
[InlineData(SentryLevel.Error)]
[InlineData(SentryLevel.Fatal)]
public void CaptureEvent_ErroredMessageWithoutException_ClosesCurrentSpanAsInternalError(SentryLevel level)
Copy link
Member

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.

Copy link
Collaborator Author

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.

@bruno-garcia bruno-garcia merged commit b8aee28 into main Nov 8, 2021
@bruno-garcia bruno-garcia deleted the fix/message-only-errors-not-closing-span branch November 8, 2021 20:52
@SimonCropp
Copy link
Contributor

so this was a breaking change since it removed public static class SentryEventExtensions

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Bug Something isn't working
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants