sentry-javascript: Sentry in Vue app causes freeze / 100% CPU usage (inf. recursion) [includes minimal example]

Review the documentation: https://docs.sentry.io/
Search for existing issues: https://github.com/getsentry/sentry-javascript/issues #2611 and #2470 seem similar to this, but are not really the same imho
Use the latest release: https://github.com/getsentry/sentry-javascript/releases
Provide a link to the affected event from your Sentry account -> Not needed, reproducible with an arbitrary DSN

Package + Version

@sentry/browser 5.25
@sentry/node
raven-js
raven-node (raven for node)
other:

Version:

vue 2.6.12
vue-router 3.4.6
bootstrap-vue 2.17.3
sentry-javscript 5.25

Description

We have a Vue application and we encountered an issue when we added sentry. We can reproduce the situation in Chrome/Chromium/Firefox both Linux,Mac and Windows (sometimes the window just freezes without maxing out cpu usage) so it does not seem to be fully platform dependent. I tried to narrow down the issue and I provide a minimal reproducible example (70 lines of html) along with gif recordings of the problem.

I am open to providing more information, helping with the investigation or even creating a PR if pointed the right way.

The Setup

The Vue application uses these libraries:

vue-router = standard library for displaying views on specific routes
bootstrap-vue = library with various components which look good (in our example, we use the scrollspy directive which it provides https://bootstrap-vue.org/docs/directives/scrollspy )

Esentially what we have is a bunch of blocks below each other (left) and a navigation with fixed position (right) which includes a button for each of the blocks on the page. We want to achieve a standard behaviour which includes:

when you scroll around the page, the currently visible block is highlighted in the navigation
when you scroll around, your url hash is dynamically updated to reflect the currently scrolled block
when you click a block in the right menu, you are taken to that block on the page (standard href behaviour)

So essentially, it works and looks like this (note the cpu usage in bottom right, as expected some load is on the windowserver but all seems fine):

CleanShot 2020-10-07 at 17 54 07

The problem

The moment we add sentry, with an existing dsn, or with the example text like this:

Sentry.init({
  dsn: "https://examplePublicKey@o0.ingest.sentry.io/0",
  integrations: [new Sentry.Integrations.Vue({ Vue, attachProps: true })],
})

This is what happens - after a while, the cpu usage of the browser process jumps to 100% and the page starts to lag:

CleanShot 2020-10-07 at 17 52 05

Eventually (depends on the machine, but on my mbp2017 it is about 30 secs), the browser console starts to fill with a bunch of errors (call stack size limit exceeded and 429+400 from sentry). During this, we also get rate limited by sentry (in our sentry project, running into this resulted in about 1000 events over those 30 seconds).

Reproduction

I am providing a minimal reproducible example for this here (single html file, 70 lines): https://github.com/Zajozor/reproducible/blob/main/sentry-javascript/index.html

(Be sure to turn off uBlock or other blocker that might block sentry if you try this 😅 )

The problem happens when you open the page, and just do what is depicted on the gif above for a while (may take from 5 secs to 20 secs for it to kick in). When you comment the lines 66-69 then the problem disappears (ie. the site has expected cpu usage).

It might be that we are doing something wrong in our code, but there is literally no issue with it until you enable sentry.

Thanks for your time 😃

About this issue

Original URL
State: closed
Created 4 years ago
Reactions: 11
Comments: 34 (13 by maintainers)

Most upvoted comments

Sentry.init({
  dsn: "https://examplePublicKey@o0.ingest.sentry.io/0",
  integrations: [
    new Sentry.Integrations.TryCatch({ eventTarget: false }),
    new Sentry.Integrations.Vue({ Vue, attachProps: true })
  ]
})

This will fix the issue, for now. However, I need more time to get into the internals and debug what is actually going on between Vue and this feature.

kamilogorek on Oct 21, 2020

Use the latest version and if that still reproduces then provide reproduction. How else do you expect that devs would figure out your problem and fix it?

So this is a very unhelpful comment.

First, the issue has been identified, it’s a problem with their walk function. It doesn’t detect circular references and will keep walking until the browser runs out of memory.

Second, reproduction steps have been provided: use a router guard that redirects to a different page and the error that it throws will cause this issue. Though I expect this can be reproduced in any framework by simply throwing an error that contains circular references.

Third, this is a paid product. I’m grateful that their libraries are open source and people can suggest modifications and see the inner workings but my company pays for this service. I don’t think it’s ridiculous to expect a common use-case (router guards) on a framework that’s in the top 3 (Vue) of frameworks used (along with Angular and React) to be supported.

Lastly, this is a nasty bug that’s been around for 18 months, I don’t think my exasperation/annoyance was uncalled for. As I said before, a bug catching/reporting tool should never be the cause of a bug itself. It would be like if your fire extinguisher spontaneously combusted and burned down your house. Until you’ve spent a good day or more of time tracking down “Your website freezes and causes the tab to eventually crash” only to find it was your bug catching tool then I don’t think you can fully appreciate the frustration involved.

I am very thankful this is being looked into and I know it’s a solvable problem. In fact, I installed rollbar last night as an alternative and it handled this same error without issue (I would prefer to switch back to sentry).

joshstrange on May 10, 2022

I’m also running into this issue. Sentry hangs whenever Vue Router throws the following error: Error: Redirected when going from 'x' to 'y' via a navigation guard.

nmackey on Dec 23, 2021

The following may sound bad but stick with me: We will most likely not adjust this behaviour.

That makes perfect sense given what you found and I really appreciate you all digging into this more. I’m not 100% sure where the depth: 20 came from originally (I want to say the docs but it might have been from some blog/tutorial I found) but I’m glad that we can re-add this integration safely.

I tested 7.0.0-beta.1 and set my depth to 4 and I was unable to reproduce. When 7.0.0 (stable) comes out we will move to that and re-add the ExtraErrorData integration.

Thank you again for your help!

joshstrange on May 17, 2022

@joshstrange I took a look at your reproduction case. Thanks again for providing it! I believe the slowdown happens here because the ExtraErrorData integration attaches data about the matched routes. This data happens to be huge, resulting in a ton of computation when serializing it. Additionally, vue doesn’t seem to like it when we try to access certain fields of this data, and we read all the fields, so it logs out a lot of bunch of errors (which might actually cause the slowdown - the CaptureConsole integration will only amplify this).

The following may sound bad but stick with me: We will most likely not adjust this behaviour.

I think we can resolve this issue through configuration. Basically what it boils down to, is that the depth option you passed to the ExtraErrorData integration is too large for the size of the payload - we are trying to serialize way too much data. In the current version of the SDK, we have the issue that depth always needs to be more than normalizeDepth. We identified that this sucks and provided a fix for that in version 7.0.0-beta.1. In that version you can keep normalizeDepth at 20 but set depth to something sane like 3. This will prevent the SDK from walking the entirety of the data and should resolve the slowdown.

Can you try upgrading to version 7.0.0-beta.1, set the depth option to a smaller value (maybe 4 or 5?), and report back whether that helped?

As for the original issue: I believe this is unrelated so we will keep this issue open and investigate further.

lforst on May 17, 2022

My fault I let this one slip through. Slamming it on our Jira board and we will keep posted with our analysis and progress

smeubank on May 10, 2022

Is this going to be addressed? I’m concerned that bugs like this in the Sentry SDK (via sentry-electron) will unpredictably crash my app which is unacceptable for my users and engineers.

aguynamedben on Dec 8, 2021