Tracing for Angular is not well integrated into route navigations

[scic]

• Review the documentation: https://docs.sentry.io/
• Search for existing issues: https://github.com/getsentry/sentry-javascript/issues
• Use the latest release: https://github.com/getsentry/sentry-javascript/releases
• Provide a link to the affected event from your Sentry account

Package + Version

• @sentry/angular

Version:

5.29.0

Description

I have a feeling that the sentry tracing integration for single page apps or at least for Angular is conceptually wrong and not usable.

The following problems:

• Each transaction (shown in the transaction summary) has the name of the initiating page load and lasts for up to 24 hours and it shows navigation events for different angular pages.
• A pageload event inside a transaction has a duration of up to 24hr
• Events in a transaction summary can be for different "pages" meaning routing navigations
• A transaction is only created for refreshes of the browser page (full page reloads)
• The sample rate is determined per transaction and thus a user is either completely tracked for up to 24 hours with all routing navigations or not at all.

Expected behavior:

• Each routing change (=navigation) in angular leads to a transaction with the url as transaction name. So that we have a statistic for each seperate angular page (routing navigation).
• pageload events should finish after the idle period after a NavigationEnd routing event has occurred
• the sample rate should be applied to each route navigation

In summary a think a new transaction for each angular route navigation should be created.
Less important: pageloads and navigations would not be summed up in the same transaction, so that we have a different statistic if a page was loaded via pageload or route navigation.

We integrated tracing via the provided default routingInstrumentation.

[scic]

The issue #3134 might be contributing to the described behavior.

[PixelBumper]

This sounds like a sensible change. However, what should happen on NavigationError or NavigationCancel?

[Tokap]

I'm encountering the same behavior in Vue. Any chance of this topic being addressed or discussed further?

[mtarregh]

Our route-tracing improved when we adjusted the navEnd observable in the routingInstrumentation to account for NavigationCancel and NavigationError events. (taken from here):

public navEnd$: Observable<Event> = this._router.events.pipe(
  filter(event => event instanceof NavigationEnd || event instanceof NavigationCancel || event instanceof NavigationError),
  tap(() => {
    if (this._routingSpan) {
      runOutsideAngular(() => {
        // eslint-disable-next-line @typescript-eslint/no-non-null-assertion
        this._routingSpan!.finish();
      });
      this._routingSpan = null;
    }
  })
);

Maybe that should be integrated into the default Angular routingInstrumentation? Because the routing still ends when the navigation is cancelled. Otherwise the route-span just stays open.

[joecotton-jamf]

I would really like this to be fixed, it makes the Sentry tracing useless for tracking pageloads in Angular apps with routing :/

[Lms24]

Hi everyone, I'm curious as to how much from this issue is still causing problems for folks.

• Each transaction (shown in the transaction summary) has the name of the initiating page load and lasts for up to 24 hours and it shows navigation events for different angular pages.
• A pageload event inside a transaction has a duration of up to 24hr

I'm using the Angular(-ivy) SDKs in various test projects and hobby projects of mine and page load transactions do finish for me after a couple of seconds, when the browser idles. This is intended behaviour of our IdleTransaction class that is used when starting the page load transaction.

Our route-tracing improved when we adjusted the navEnd observable in the routingInstrumentation to account for NavigationCancel and NavigationError events

This makes sense to me. I'll open a PR to add these events to the filter. We should finish the routing span in any case when a navigation finishes, not just in the success case.

If anyone is still experiencing 24h pageload transactions, please provide a minimal reproduction (code or even better a gh repo with the reproducible behaviour) so we can look into it. Since in the meantime I'm unable to reproduce this, I'll close the issue once #8369 is merged