Repository navigation
Tracing finalTimeout blocks Angular Zone stabilisation #8983
Description
Is there an existing issue for this?
- I have checked for existing issues https://github.com/getsentry/sentry-javascript/issues
- I have reviewed the documentation https://docs.sentry.io/
- I am using the latest SDK release https://github.com/getsentry/sentry-javascript/releases
How do you use Sentry?
Sentry Saas (sentry.io)
Which SDK are you using?
@sentry/angular-ivy
SDK Version
7.57.0
Framework Version
Angular 15.2.0
Link to Sentry event
No response
SDK Setup
this.ngZone.runOutsideAngular(() => {
const tracingIntegrations =
tracesSampleRate !== undefined
? [
new Sentry.BrowserTracing({
tracePropagationTargets: [
'localhost',
this.httpConfig.baseUrl,
/^\//,
],
}),
]
: [];
Sentry.init({
dsn: this.config.sentryDsn,
release: "...",
environment: this.environment,
ignoreErrors: [
// <snip>
],
allowUrls: !this.pwa.isNative() ? [/\/assets\//] : undefined,
denyUrls: [/^file:\/\//, /^moz-extension:\/\//],
integrations: integrations =>
// integrations will be all default integrations
[
...integrations.filter(
integration =>
!['TryCatch', 'GlobalHandlers'].includes(integration.name),
),
new SentryIntegrations.ExtraErrorData(),
new SentryIntegrations.ReportingObserver(),
...tracingIntegrations,
],
tracesSampler: context => {
if (context.location?.search.includes('sentry-tracing=true')) {
return 1;
}
return tracesSampleRate ?? 0;
},
});
}); Steps to Reproduce
- Trigger a
pageloadornavigationoperation
Expected Result
Angular's zone should stabilize and appRef.isStable/testability.whenStable should emit after network requests have finished and app is stable.
eg. code like this should log:
this.testability.whenStable(() => {
console.log("App is stable.");
});Actual Result
NgZone doesn't stabilise because of a pending timeout from finalTimeout. It only stabilises after 30 seconds (the default value of the finalTimeout), even if the idle timeout and heartbeat interval have already completed.
We utilise the stability API for a number of things (e2e tests, performance tracking) which have been affected by upgrading from Sentry 6 to 7. Our e2e tests against our dev environment take longer to run, and long task tracking is less accurate.
We've worked around it partially by running Sentry.init outside of the Angular zone (see snippet above) but this only affects the pageload event and not future navigations.
I've tested this using @sentry/browser, @sentry/angular and @sentry/angular-ivy and the behaviour is the same.
Thanks.
Metadata
Metadata
Assignees
Projects
- Status
- Status
Activity
Lms24 commentedon Sep 8, 2023
Hi @henry-alakazhang thanks for writing in!
The reason why we need this timeout (
finalTimeout) is because ourBrowserTracingintegration startsIdleTransactions on navigations and pageloads that finish themselvse (as opposed to anyone callingtransaction.finish()after a period of inactivity.A question: Is there a reason why you're not using our Angular routing instrumentation as shown in our docs? Similarly, are you using
TraceService? Both things are required to get proper transactions for pageloads and navigations in Angular.I'm curious if using routing instrumentation and TraceService change anything w.r.t to this behaviour.
Otherwise, I don't think we can get rid of the
finalTimeoutfrom our idletransactions.Do you think starting the idle transactions outside the NgZone would make a difference here?
henry-alakazhang commentedon Sep 8, 2023
Thanks for the response @Lms24.
The
Sentry.initI copied is from our current codebase which hasn't been migrated to@sentry/angularyet, but I did test swapping to@sentry/angular, including the routing instrumentation and TraceService, and it still had the same result. I'm pretty sure I set it up correctly as I was seeing the full navigation event in the transaction and the routes were pulled from the router correctly.Yeah, that'd be one way to fix the issue.
I'm curious though if there's a reason the
finalTimeoutcontinues to run even when theIdleTransactionis done. Before v7 there was still a max duration but it didn't seem to add a pending timer to the zone.Lms24 commentedon Sep 8, 2023
That's an interesting observation, thanks! We'll take a look at this in greater detail next week. Maybe there's something we can fix more generally here; otherwise I'll go with running outside the ngzone.
AbhiPrasad commentedon Sep 8, 2023
Yeah this was done on purpose because we didn't want there to be a infinitely running transaction, so we used a timeout to hard cut it off.
I wonder if we should use
appRef.isStableto end transactions in angular instead of relying on timeouts 🤔. We can then create regular transactions instead of idle ones.arturovt commentedon Apr 26, 2024
Considering the changes made in #11703 and #11748 to the Angular tracer and error handler, it should now be possible to fix all of the issues you may have been facing previously. All of the Sentry functionality is now running outside of the Angular zone, meaning Angular is unaware of any tasks being scheduled within its context. As a result, server-side rendering, hydration, and early stabilization would now only rely on tasks being scheduled explicitly by the consumer.
If you're still facing any issues, I can guide you through the process of identifying which tasks are preventing the application from becoming stable and determining if Sentry is the cause of them.
Lms24 commentedon Jul 5, 2024
I'm gonna close this issue as to the best of my knowledge this was addressed in the PRs mentioned in the comment above. Please let me know if it should be reopened.