Unable to initialize Sentry SDK - "utils_1.PromiseBuffer is not a constructor" #5116

Activity

1. simmons-kyle

   added

   Type: Bug

   on May 17, 2022
2. getsantry

   added

   Status: Untriaged

   on May 17, 2022
3. Lms24 commented on May 17, 2022

   

   Lms24

   on May 17, 2022

   Last edited by Lms24

   Member

   More actions

   HI @simmons-kyle and thanks for writing in!

   Have you tried reproducing this behaviour with our beta version of v7? If not, I'd recommend installing @sentry/node@7.0.0-beta.1 (beta.2 will be out very soon) and trying if this fixes it. We made a lot of changes to our clients and transports which makes it particularly interesting to see if the problem is still there.

   Also on that note: are you passing any special options to Sentry.ini (e.g. a custom transport, special integrations, etc)?

   Hope this helps

   EDIT: Here's the link to our v7 migration guide
4. Lms24

   added

   Status: Needs Information

   Status: Needs Reproduction

   and removed

   Status: Untriaged

   on May 17, 2022
5. simmons-kyle commented on May 18, 2022

   

   simmons-kyle

   on May 18, 2022

   Last edited by simmons-kyle

   Author

   More actions

   Hey @Lms24 - here's the options object we pass to our Sentry.init call:

   {
       dsn: config.SENTRY_DSN,
       release: config.APP_BUILD,
       environment: config.APP_ENV,
       autoSessionTracking: true,
       attachStacktrace: true,
       // @ts-ignore
       sendDefaultPii: true,
       tracingOptions: {
           trackComponents: true,
       },
       integrations: [
           new Integrations.CaptureConsole({
           levels: ['error'],
           }),
       ],
       tracesSampleRate: sampleRate,
       logErrors: true,
     }
   

   Is there anything there that could cause any red flags? We've verified that the values stored within variables (i.e. the config object for SENTRY_DSN, APP_BUILD, APP_ENV and sampleRate) are present and correct too.

   EDIT - We are now seeing a slightly different error on other functions that consume the same Sentry.init call (even when using the package version I suspected resolved this issue). This time it relates to utils_1.Dsn:

   'TypeError: utils_1.Dsn is not a constructor' Stack: TypeError: utils_1.Dsn is not a constructor at NodeBackend._setupTransport (D:\home\site\wwwroot\node_modules@sentry\node\dist\backend.js:97:19) at NodeBackend.BaseBackend (D:\home\site\wwwroot\node_modules@sentry\core\dist\basebackend.js:15:32) at new NodeBackend (D:\home\site\wwwroot\node_modules@sentry\node\dist\backend.js:15:42) at NodeClient.BaseClient (D:\home\site\wwwroot\node_modules@sentry\core\dist\baseclient.js:53:25) at new NodeClient (D:\home\site\wwwroot\node_modules@sentry\node\dist\client.js:33:24) at Object.initAndBind (D:\home\site\wwwroot\node_modules@sentry\core\dist\sdk.js:18:18) at Object.init (D:\home\site\wwwroot\node_modules@sentry\node\dist\sdk.js:116:12)`
6. Lms24 commented on May 18, 2022

   

   Lms24

   on May 18, 2022

   Member

   More actions

   So, I took a look at the error stack and it seems weird to me that the SDK apparently tries to call constructors that aren't there. So I suspect that you might have some version mismatches in your Sentry packages. For example, the DSN class was removed in #4325 a while ago. Can you check if the versions of your Sentry packages are all the same?

   As an example, @sentry/node depends on other Sentry pacakges, such as @sentry/core or @sentry/utils. Those versions must match. Also, do you have @sentry/tracing installed? If yes, it should have the same version as the Node SDK. We generally strongly recommend to keep all Sentry packages at the same versions to avoid such problems.

   Hope this helps!

   PS: v7 introduces a few more breaking changes, so it's very important to also upgrade all packages to v7 when you're making the switch.
7. simmons-kyle commented on May 18, 2022

   

   simmons-kyle

   on May 18, 2022

   Author

   More actions

   Thanks @Lms24 - yeah we had matching versions for each of our sentry packages, however I believe we have a fix now and it's along the lines of what you suspect. What managed to fix it was removing the node_modules folder entirely and then running yarn (or npm install) again.

   We had some back and forth on our repo with the versions changing and there must have been some dependencies which were out of sync along the way due to that. Having a fresh install seemed to resolve the issues.
8. simmons-kyle

   closed this as completedon May 18, 2022
9. Lms24

   added

   Type: Support

   Status: As Designed

   Status: Solved

   and removed

   Type: Bug

   Status: Needs Information

   Status: Needs Reproduction

   on May 18, 2022