Skip to content

fix(apm): Check activities count before finishing idle transaction #2672

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
wants to merge 3 commits into from

Conversation

AbhiPrasad
Copy link
Member

@AbhiPrasad AbhiPrasad commented Jun 15, 2020

After an idle transaction timeout, we should check to see if the activities count is still 0 before finishing a transaction.

Also fixed some spelling/grammar mistakes.

@AbhiPrasad AbhiPrasad force-pushed the abhi/fix/idle-transaction-finish branch from efbdc9e to ed26a7e Compare June 15, 2020 19:34
@AbhiPrasad AbhiPrasad changed the title fix(apm): Check activities count in idle transaction fix(apm): Check activities count before finishing idle transaction Jun 15, 2020
@AbhiPrasad AbhiPrasad marked this pull request as ready for review June 15, 2020 19:34
@AbhiPrasad AbhiPrasad requested a review from kamilogorek as a code owner June 15, 2020 19:34
@getsentry-bot
Copy link
Contributor

getsentry-bot commented Jun 15, 2020

Messages
📖

@sentry/browser bundle gzip'ed minified size: (ES5: 17.0996 kB) (ES6: 16.1699 kB)

📖 ✅ TSLint passed

Generated by 🚫 dangerJS against 8af8fd8

Comment on lines +864 to +866
if (Object.keys(Tracing._activities).length === 0 && Tracing._activeTransaction) {
Tracing.finishIdleTransaction(end);
}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We have to be careful here. I tinkered around with this for a long time.
While in your specific example it might improve the transaction, in other cases this has the potential of not sending the transaction at all.
Also, this change was made on purpose, before (see git history) we have a debouce timer that kept the Transaction alive which resulted in may weird very long Transaction. This change was made so after all the initial requests are done and the first "idle" occurs, we finish the Transaction no matter what (to prevent long transactions).
We finish Span that would have been started and mark them as cancelled.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I see. The issue here is that right now the moment the activities goes to 0, the idle transaction ends.

I see what you mean by long running transaction (like if a page keeps creating single activities), but a user can easily just adjust the timeout option to instantly call finish idle transaction.

We could also apply a heuristic here, and say something like if the activities went from 0 -> 1 -> 0 -> 1 a certain amount of times, we should just end the idle transaction.

This change should still lead to transactions finishing through the heartbeat though right?

Right now testing on multiple Sentry pages, a single page load fails to account for a lot of our requests, and I’d rather optimize for that use case then 0 -> 1 -> 0 ->1 causing long running transactions.

@AbhiPrasad
Copy link
Member Author

After discussing with Daniel, we are closing this PR to investigate this issue some more.

Points to figure out

  • What are the use cases we want to account for (and then turn them into integration tests)
  • Clash between history callback navigation/pageload - is there a possibility for some race condition here?
  • Should we increase the default idleTimeout of idle transactions?

I will be cherry-pick the spelling changes from this branch into another PR.

@AbhiPrasad AbhiPrasad closed this Jun 16, 2020
@AbhiPrasad AbhiPrasad deleted the abhi/fix/idle-transaction-finish branch June 16, 2020 15:44
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants