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鈥檒l occasionally send you account related emails.
Already on GitHub? Sign in to your account
Remove SentryTransaction from public API #1304
Conversation
@@ -73,6 +73,11 @@ protected void doFilterInternal( | |||
if (hub.isEnabled()) { | |||
final String sentryTraceHeader = httpRequest.getHeader(SentryTraceHeader.SENTRY_TRACE_HEADER); | |||
|
|||
hub.configureScope( |
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.
ITransaction#setRequest
is deprecated now as these kind of properties should be set on the scope and then applied to transaction in SentryClient
.
@@ -424,6 +431,16 @@ public void captureSession(final @NotNull Session session, final @Nullable Objec | |||
return transaction; | |||
} | |||
|
|||
private @NotNull SentryTransaction applyScope( |
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.
Here very likely we should populate transactions with more data, i just don't want to put everything into single 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.
true, we have an issue for that already
@Deprecated | ||
@ApiStatus.ScheduledForRemoval | ||
public void setRequest(@Nullable Request request) { | ||
hub.configureScope(scope -> scope.setRequest(request)); |
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 is not great - ideally we would remove these methods already as it may be surprising to set request on a transaction and realise that it's set on the scope.
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 wonder if there are 2 transactions running at the same time and both call setRequest
, they are gonna overwrite each other (at least on Android)
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.
We could just have a request
field for now and when you do var transation = new Transation
you set the fields into that. Same for anything else we need to call into the scope like this.
The deprecation note is there so later we can drop the code on next major.
Would this work?
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.
Yep, done that.
Few tests are still todo and likely some polishing in tests, other than that, please take another look @marandaneto @bruno-garcia |
Codecov Report
@@ Coverage Diff @@
## main #1304 +/- ##
============================================
- Coverage 75.81% 75.62% -0.19%
- Complexity 1796 1830 +34
============================================
Files 183 185 +2
Lines 6227 6302 +75
Branches 622 624 +2
============================================
+ Hits 4721 4766 +45
- Misses 1227 1250 +23
- Partials 279 286 +7
Continue to review full report at Codecov.
|
* @return true if transaction has been successfully finished or false if span has been already | ||
* finished | ||
*/ | ||
boolean finish(); |
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.
wondering why we need to return a boolean 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.
Look into SentryTracer#finish
- we need to know if finishing the root span ended up in finishing or not.
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.
Also a bit surprised about returning this.
It's also a breaking change.
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.
Now moved back to void
. Technically it's possible that SentryTracer#finish
will be invoked by two threads, only one will finish the root span and both will capture the same transaction. As far as I can see transactions are de-duplicated on the Sentry backend side, and it's not something that is likely to happen, so I guess it can stay as it is right now.
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.
But there's no need to return to the user whether it was captured or not due double calling it though so void works fine
* @return true if transaction has been successfully finished or false if span has been already | ||
* finished | ||
*/ | ||
boolean finish(); |
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.
Also a bit surprised about returning this.
It's also a breaking change.
@Deprecated | ||
@ApiStatus.ScheduledForRemoval | ||
public void setRequest(@Nullable Request request) { | ||
hub.configureScope(scope -> scope.setRequest(request)); |
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.
We could just have a request
field for now and when you do var transation = new Transation
you set the fields into that. Same for anything else we need to call into the scope like this.
The deprecation note is there so later we can drop the code on next major.
Would this work?
@marandaneto good to merge? |
sentry-spring/src/test/kotlin/io/sentry/spring/tracing/SentryTransactionAdviceTest.kt
Outdated
Show resolved
Hide resolved
if (transaction == this) { | ||
scope.clearTransaction(); | ||
} |
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 guess we are introducing the same bug here, how do we know we are clearing the right transaction? and if its another one? we used to do an equal check, we need to find a way 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.
Since we are inside withTransaction
, does the lock prevent from setting any transaction during this operation?
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.
ops sorry, I read transaction == null
instead of this
:D
init { | ||
val options = SentryOptions() | ||
options.dsn = "https://key@sentry.io/proj" | ||
hub = spy(Hub(options)) |
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.
just out of curiosity, what would be the benefit of using spy
instead of mock
as usual? are we asserting the hub
itself? if so, should we not test that thru the HubTest class?
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.
With using mock we can't really test that transaction is cleared from the scope. If we use mock for finish
method, we won't really test much.
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.
LGTM
huge win, thanks!
馃摐 Description
Remove SentryTransaction from public API & use separate classes for user facing & protocol operations in the Performance feature.
馃挕 Motivation and Context
馃挌 How did you test it?
Unit tests.
馃摑 Checklist