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

Transactions/Spans finished without status or associated error #1351

Closed
marandaneto opened this issue Mar 24, 2021 · 6 comments
Closed

Transactions/Spans finished without status or associated error #1351

marandaneto opened this issue Mar 24, 2021 · 6 comments
Assignees
Labels
enhancement New feature or request performance Performance API issues

Comments

@marandaneto
Copy link
Contributor

SentrySpanAdvice and SentryOkHttpInterceptor do finish a span either with SpanStatus.OK or SpanStatus.INTERNAL_ERROR (or depending on HTTP response code), also associates the error to the span if any.

SentrySpanClientHttpRequestInterceptor does not set an status if execution.execute throws nor associates the error.

SentryTracingFilter does not associate the error if any.

SentryTransactionAdvice does not set a status if invocation.proceed throws nor associates the error.

@marandaneto marandaneto added enhancement New feature or request performance Performance API issues labels Mar 24, 2021
@marandaneto
Copy link
Contributor Author

@maciejwalkowiak let me know if it was designed like this or just an oversight.

@maciejwalkowiak
Copy link
Contributor

SentrySpanClientHttpRequestInterceptor - execution.execute does not throw when HTTP status != 2xx, but indeed IOException could happen so we should handle this.

SentryTracingFilter - since exception happens within the scope of transaction it gets associated with the trace in SentryClient.

SentryTransactionAdvice - you're right, will fix it.

@marandaneto
Copy link
Contributor Author

@Tyrrrz please also double-check that on .NET we do cover those cases, we need to finish the span with status either successfully or not, even associating its error whenever possible.

@marandaneto
Copy link
Contributor Author

Requires #1421

@marandaneto
Copy link
Contributor Author

@maciejwalkowiak can I close this? I guess every change has been tackled right

@maciejwalkowiak
Copy link
Contributor

Yep

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request performance Performance API issues
Projects
None yet
Development

No branches or pull requests

2 participants