Description
- 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/browser
-
@sentry/vue
-
@sentry/tracing
Version:
6.17.6
Description
Consider this transaction:
This transaction is created using vueRouterInstrumentation
, in a fairly normal method:
Even though there are multiple API calls in progress which have not reached the 1000ms transaction timeout, the transaction is still closed and these calls are dropped. I've traced this to this particular line in the code:
sentry-javascript/packages/tracing/src/idletransaction.ts
Lines 224 to 229 in 6abb463
As far as I can tell, the intention here for IdleTransaction is:
- Keep track of all open spans as they are pushed and popped
- When all open spans are closed, start a timer
- If no spans are created in that time period, close the transaction
- additionally, run a 5s heartbeat and if no change whatsoever for 3 full beats, close the transaction
However, what this code is actually implementing is "when all open spans are closed, close the transaction immediately as soon as the idleTimeout is reached." It doesn't matter at that point if there are more spans which are added after that point, no matter how active the transaction is, it will be forcibly closed as soon as the timeout is hit. This is obvious by looking at this graph above - the transaction is closed exactly 1000ms after the first span closes and the transaction returns to 0 activities, even though a bunch of other activities are kicked off immediately afterwards and the transaction is nowhere near idle when it is closed.
Is this the true intention for IdleTransaction? If so, why, and how can I stop this from happening? It's cutting off my performance data and severely under-representing the actual time it takes for a navigation to complete and the page to be fully loaded and visible. This type of waterfall requests/rendering is pretty common for webapps, this feels like a major issue to me.