feat: UI events transactions

[romtsn]

📜 Description

• Adds idleTimeout to SentryTracer to finish idled transaction
• Creates a new transaction whenever a UI action is performed (click, swipe, scroll).

💡 Motivation and Context

Q1 Goal
Closes #1811

💚 How did you test it?

📝 Checklist

• I reviewed the submitted code
• I added tests to verify the changes
• I updated the docs if needed
• No breaking changes

🔮 Next steps

[github-actions]

	Messages
📖	Do not forget to update Sentry-docs with your feature once the pull request gets approved.

Generated by 🚫 dangerJS against 0161bd7

[marandaneto]

@romtsn This should target 6.x.x

[romtsn]

@romtsn This should target 6.x.x

Why?

[marandaneto]

@romtsn This should target 6.x.x

Why?

Hub interface is a public API and it has changed.

[romtsn]

@marandaneto mm, but only methods marked as Internal have changed. Only if we care about ABI, then it makes sense.

[marandaneto]

@marandaneto mm, but only methods marked as Internal have changed. Only if we care about ABI, then it makes sense.

Indeed, but I'd rather point to v6 to speed up this major release, by that I mean more people working on the new code base and testing out all the changes.
Unless @bruno-garcia says otherwise.

[romtsn]

@marandaneto mm, but only methods marked as Internal have changed. Only if we care about ABI, then it makes sense.

Indeed, but I'd rather point to v6 to speed up this major release, by that I mean more people working on the new code base and testing out all the changes. Unless @bruno-garcia says otherwise.

sounds good, have no problem with targeting 6.x.x actually!

[romtsn]

@marandaneto @philipphofmann @adinauer this is ready for review PTAL

[philipphofmann]

Overall the PR looks great. Thanks for all the effort. Maybe I missed it, but I'm not sure if the code handles the following scenario:

Scenario: Ongoing UI event transaction
   Given an ongoing UI event transaction
   When the SDK creates a new screen load transaction
   Then the SDK finishes the previous transactions
   And removes it from the scope
   And sets the status to canceled
   And waits for its children to finish

[philipphofmann]

m: Can we also add a test for when the idle timeout expires, but the transaction has still an unfinished child. I think we should then wait for the child to finish.

[romtsn]

But we said we cancel the timer when a new child is added and reset it when the last child is finished, so there's technically no idle timeout while there's an ongoing child span.

Even though, this has been missing in my code, so I'll update that, thanks for the point.

[philipphofmann]

Yes, makes sense. Thanks for the clarification.

[marandaneto]

@romtsn please update the PR Checklist

[romtsn]

Overall the PR looks great. Thanks for all the effort. Maybe I missed it, but I'm not sure if the code handles the following scenario:

Scenario: Ongoing UI event transaction
   Given an ongoing UI event transaction
   When the SDK creates a new screen load transaction
   Then the SDK finishes the previous transactions
   And removes it from the scope
   And sets the status to canceled
   And waits for its children to finish

Yeah, this is done here ->

sentry-java/sentry-android-core/src/main/java/io/sentry/android/core/internal/gestures/SentryGestureListener.java

Lines 265 to 276 in f67519e

	void stopTracing(final @NotNull SpanStatus status) {
	if (activeTransaction != null) {
	activeTransaction.finish(status);
	}
	hub.configureScope(
	scope -> {
	clearScope(scope);
	});
	activeTransaction = null;
	activeView.clear();
	activeEventType = null;
	}

With the only difference that we do this when the current screen goes inactive (onPause). This makes sense for us, because we use android's WindowCallback, which will get detached as soon as the activity/screen goes inactive, therefore it wouldn't make sense for us to wait until the new screen transaction, but rather finish it here.

[codecov-commenter]

Codecov Report

Merging #1975 (bdcd818) into 6.x.x (d1c8c4d) will increase coverage by 0.07%.
The diff coverage is 85.05%.

@@             Coverage Diff              @@
##              6.x.x    #1975      +/-   ##
============================================
+ Coverage     80.79%   80.86%   +0.07%     
- Complexity     3146     3169      +23     
============================================
  Files           228      228              
  Lines         11645    11714      +69     
  Branches       1565     1577      +12     
============================================
+ Hits           9409     9473      +64     
- Misses         1649     1650       +1     
- Partials        587      591       +4     

Impacted Files	Coverage Δ
sentry/src/main/java/io/sentry/Hub.java	75.72% <ø> (ø)
sentry/src/main/java/io/sentry/HubAdapter.java	8.19% <ø> (ø)
sentry/src/main/java/io/sentry/IHub.java	87.50% <0.00%> (-3.81%)	⬇️
sentry/src/main/java/io/sentry/NoOpHub.java	48.78% <ø> (ø)
...entry/src/main/java/io/sentry/NoOpTransaction.java	25.80% <0.00%> (-0.87%)	⬇️
sentry/src/main/java/io/sentry/Sentry.java	45.06% <ø> (ø)
sentry/src/main/java/io/sentry/SentryTracer.java	91.17% <83.01%> (+0.37%)	⬆️
...main/java/io/sentry/config/PropertiesProvider.java	90.00% <85.71%> (-10.00%)	⬇️
...entry/src/main/java/io/sentry/ExternalOptions.java	100.00% <100.00%> (ø)
sentry/src/main/java/io/sentry/SentryOptions.java	81.74% <100.00%> (+0.85%)	⬆️
... and 4 more

---

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 d1c8c4d...bdcd818. Read the comment docs.

[romtsn]

Reverted frame metrics as we'll do it as part of #2101