You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
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.
The text was updated successfully, but these errors were encountered:
aha! I did a search or two to see if this was already open but apparently I didn't search for the right things (namely, an already open PR). that's excellent to hear, I will take my feedback there!
Package + Version
@sentry/browser
@sentry/vue
@sentry/tracing
Version:
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:
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.
The text was updated successfully, but these errors were encountered: