Skip to content
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

App fails to boot or boots extremely slowly on Google cloud run when on @sentry/profiling-node versions 8.37.0 and later #14388

Open
3 tasks done
Blargel opened this issue Nov 20, 2024 · 12 comments
Labels
Package: nestjs Issues related to the Sentry Nestjs SDK Waiting for: Product Owner

Comments

@Blargel
Copy link

Blargel commented Nov 20, 2024

Is there an existing issue for this?

How do you use Sentry?

Sentry Saas (sentry.io)

Which SDK are you using?

@sentry/nestjs

SDK Version

8.38.0

Framework Version

Node 22.6.0, @nestjs/core 10.4.8, @nestjs/apollo 12.2.1

Link to Sentry event

No response

Reproduction Example/SDK Setup

Unfortunately, I do not have a proper reproduction example, due to the nature of the bug that I'm experiencing, but here is how I have things set up.

instrument.js

import * as Sentry from '@sentry/nestjs'
import { nodeProfilingIntegration } from '@sentry/profiling-node'

import { config } from './config'

if (config.sentry.dsn != null) {
  Sentry.init({
    integrations: [nodeProfilingIntegration()],
    ...config.sentry, // This is controlled by env vars. In the failing environments, they're all the values used in documentation without any changes, except the DSN.
  })
}

app.module.js

import { Module, ValidationPipe } from '@nestjs/common'
import { APP_FILTER, APP_GUARD, APP_PIPE } from '@nestjs/core'
import { SentryGlobalGenericFilter, SentryModule } from '@sentry/nestjs/setup'

import { AuthenticationGuard } from './authentication/authentication.guard'
import { AuthenticationModule } from './authentication/authentication.module'
import { SupertokensExceptionFilter } from './authentication/supertokens-exception.filter'
import { AuthorizationGuard } from './authorization/authorization.guard'
import { AuthorizationModule } from './authorization/authorization.module'
import { ContextModule } from './context/context.module'
import { TypeOrmConfigModule } from './db/typeOrmConfig.module'
import { GraphQLModule } from './graphql/graphql.module'
import { HealthModule } from './health/health.module'
import { RestModule } from './rest/rest.module'
import { SuperTokensModule } from './services/superTokens/superTokens.module'
import { TransactionModule } from './utils/interceptors/transaction/transaction.module'

@Module({
  imports: [
    AuthenticationModule,
    AuthorizationModule,
    ContextModule,
    GraphQLModule,
    HealthModule,
    RestModule,
    SuperTokensModule,
    TransactionModule,
    TypeOrmConfigModule,
    SentryModule.forRoot(),
  ],
  providers: [
    {
      provide: APP_GUARD,
      useClass: AuthenticationGuard,
    },
    {
      provide: APP_GUARD,
      useClass: AuthorizationGuard,
    },
    {
      provide: APP_PIPE,
      useFactory: () => new ValidationPipe({ whitelist: true }),
    },
    {
      provide: APP_FILTER,
      useClass: SupertokensExceptionFilter,
    },
    {
      provide: APP_FILTER,
      useClass: SentryGlobalGenericFilter,
    },
  ],
})
export class AppModule {}

Steps to Reproduce

Unfortunately, I cannot give proper reproduction steps, but I can describe whatt happened before, during, and after the appearance of this bug once we encountered it.

Our application was working fine and then we updated some dependencies, including @sentry/nestjs and @sentry/profiling-node. After these updates, our tests passed and the application ran locally perfectly fine. However, when deployed to our dev environment, which is hosted on Google Cloud Run, the startup probe failed to get a response. After investigating, it seemed like the application was failing to boot sometimes, or booting extremely slowly other times. We eventually narrowed down the problem to Sentry, though we're not sure how this can possibly be the case, but downgrading just the Sentry packages back to the older versions resolved the issue. We're currently pinning both package versions to 8.35.0 as that was the last version we were using that wasn't causing problems.

In my free time, I did some additional testing by changing package versions one by one to specific versions and seeing if the problem occurred. As far as my testing is concerned, @sentry/nestjs is fine no matter what version it uses, but @sentry/profiling-node causes the problem once you get to version 8.36.0 and later.

Expected Result

I expect that my application boots up normally

Actual Result

The application fails to boot, or boots extremely slowly, but only on Google Cloud Run. During troubleshooting, we placed a lot of console.log statements, including in the instrument.js file where Sentry config happens, immediately after the import statements. In the cases where the application fails to boot, nothing gets logged. In the cases where the application boots extremely slowly, it seems like importing files is taking 4x longer than usual for some reason.

@getsantry getsantry bot moved this to Waiting for: Product Owner in GitHub Issues with 👀 3 Nov 20, 2024
@github-actions github-actions bot added the Package: nestjs Issues related to the Sentry Nestjs SDK label Nov 20, 2024
@andreiborza
Copy link
Member

Hi @Blargel, thanks for filing this.

Could you try reproduce this with a fresh nestjs project on your platform with 8.36.0? Also please set debug: true in the Sentry init and paste the startup logs.

@wodCZ
Copy link

wodCZ commented Nov 21, 2024

Running into the same/similar issue on Northflank (which is k8s on top of Google Cloud).

Upgrading from @sentry/nestjs on 8.35.0 to 8.39.0 increased the startup time from 1 minute to 3 minutes.

I figured it's the require times, I guess something between these 2 versions causes the imports to take much longer - either the amount of imported files has changed massively, or the sdk does some monkey patching magic on top of require. I suspect the latter.

Notably, this slowdown isn't noticeable on "normal" server. Gcloud/northflank supposedly have some kind of security layer on top of fs, that makes IO way too slow. Anyway, that's where we run the app that uses Sentry SDK, and after the update we're having startup time issues.

As opposed to the author, we don't use @sentry/profiling-node - the issue surfaces during @sentry/nestjs upgrade.

Edit: that is on Node 22.5 & 22.11.

@getsantry getsantry bot moved this to Waiting for: Product Owner in GitHub Issues with 👀 3 Nov 21, 2024
@andreiborza
Copy link
Member

@wodCZ do you perceive this startup time increase with 8.38.0 too? We recently added instrumentation for nest's event emitter (with 8.39.0.

Also, could you try turning Sentry off completely and seeing if the startup time goes back to expected values?

@wodCZ
Copy link

wodCZ commented Nov 21, 2024

@andreiborza yes, with 8.38.0 the container won't start during the 3m "readiness" probe, causing the container to restart.

I have added this to my startup.ts

console.time('Imports time');
const path = require('node:path');

// Save the original require function
const originalRequire = module.constructor.prototype.require;

// Map to store module load times
const loadTimes = new Map<string, number>();

// Override the require function
module.constructor.prototype.require = function (moduleName: string) {
  const start = performance.now();
  const module = originalRequire.call(this, moduleName);
  const end = performance.now();

  const packageName = moduleName.split(path.sep)[0];
  const loadTime = end - start;

  if (!packageName.startsWith('.')) {
    if (loadTimes.has(packageName)) {
      loadTimes.set(packageName, (loadTimes.get(packageName) ?? 0) + loadTime);
    } else {
      loadTimes.set(packageName, loadTime);
    }
  }

  return module;
};

export function logLoadTimes() {
  console.timeEnd('Imports time');
  console.log('Module load times:');
  const sortedLoadTimes = new Map(
    [...loadTimes.entries()].sort((a, b) => b[1] - a[1]),
  );
  for (const [module, time] of sortedLoadTimes.entries()) {
    if (time < 10) {
      continue;
    }
    console.log(`${module}: ${time.toFixed(2)} ms`);
  }
}

and then added import './startup'; at the first line (before sentry instrument import), along with logLoadTimes() right before bootstrap() in my entrypoint (standard nest main.ts).

This is the truncated output before update:

2024-11-21T07:34:46.444598144Z stdout F [2024-11-21T07:34:46Z INFO ] Starting container entrypoint...
2024-11-21T07:35:55.117924635Z stdout F Imports time: 1:07.327 (m:ss.mmm)
2024-11-21T07:35:55.119541572Z stdout F Module load times:
2024-11-21T07:35:55.120906155Z stdout F @nestjs: 28546.08 ms
2024-11-21T07:35:55.120929147Z stdout F @sentry: 13554.86 ms
2024-11-21T07:35:55.121172553Z stdout F pdfkit: 6501.54 ms
2024-11-21T07:35:55.121183265Z stdout F bull: 6294.40 ms
2024-11-21T07:35:55.121196945Z stdout F @aws-sdk: 5472.87 ms
2024-11-21T07:35:55.121200808Z stdout F @opentelemetry: 5437.83 ms
2024-11-21T07:35:55.121696755Z stdout F class-validator: 4907.35 ms
2024-11-21T07:35:55.121739801Z stdout F ioredis: 4905.54 ms
2024-11-21T07:35:55.121746317Z stdout F rxjs: 4765.03 ms
2024-11-21T07:35:55.121749244Z stdout F @fastify: 3927.10 ms
2024-11-21T07:35:55.121752678Z stdout F fastify: 3781.08 ms

And this is after update, in rare cases when the container manages to start before it's killed by the scheduler:

2024-11-19T16:43:33.035903374Z stdout F [2024-11-19T16:43:33Z INFO ] Starting container entrypoint...
2024-11-19T16:46:19.362491202Z stdout F Imports time: 2:46.080 (m:ss.mmm)
2024-11-19T16:46:19.363454608Z stdout F Module load times:
2024-11-19T16:46:19.363985879Z stdout F @nestjs: 71167.86 ms
2024-11-19T16:46:19.364005263Z stdout F @sentry: 17721.53 ms
2024-11-19T16:46:19.364008897Z stdout F @aws-sdk: 15738.18 ms
2024-11-19T16:46:19.364458953Z stdout F class-validator: 14388.63 ms
2024-11-19T16:46:19.364481839Z stdout F firebase-admin: 14103.21 ms
2024-11-19T16:46:19.36448681Z stdout F rxjs: 13112.18 ms
2024-11-19T16:46:19.364844626Z stdout F @graphql-tools: 11879.51 ms
2024-11-19T16:46:19.365350044Z stdout F @fastify: 10799.17 ms
2024-11-19T16:46:19.365369132Z stdout F pdfkit: 10601.84 ms
2024-11-19T16:46:19.365937976Z stdout F fastify: 10198.69 ms
2024-11-19T16:46:19.365954733Z stdout F @opentelemetry: 9052.48 ms

I suspected Nest at the beginning, given that it has the largest jump in the logged load times, but just changing the sentry version without touching nest causes the issue to appear.

Here's a patch of yarn.lock that I tried just now - not sure whether the issue coming directly from @sentry, or the underlying @opentelemetry packages.

Index: yarn.lock
IDEA additional info:
Subsystem: com.intellij.openapi.diff.impl.patch.CharsetEP
<+>UTF-8
===================================================================
diff --git a/yarn.lock b/yarn.lock
--- a/yarn.lock	(revision bc47696b4a7b01166350c153a7983477ef1e75c6)
+++ b/yarn.lock	(revision 7e8c8e3929ce5b143f1ad641190f5dd1085186a4)
@@ -2642,6 +2642,15 @@
   languageName: node
   linkType: hard
 
+"@opentelemetry/api-logs@npm:0.54.2":
+  version: 0.54.2
+  resolution: "@opentelemetry/api-logs@npm:0.54.2"
+  dependencies:
+    "@opentelemetry/api": "npm:^1.3.0"
+  checksum: 10c0/7daaa8ad0d328102a9039b9f91474263302e14edd89f61c098667b9bc0642b24f09bae6a1899fce9b90944d5c203d0438cb4d2ded5e65954928a1f5e3c186c5d
+  languageName: node
+  linkType: hard
+
 "@opentelemetry/api@npm:^1.0.0, @opentelemetry/api@npm:^1.3.0, @opentelemetry/api@npm:^1.8, @opentelemetry/api@npm:^1.9.0":
   version: 1.9.0
   resolution: "@opentelemetry/api@npm:1.9.0"
@@ -2669,30 +2678,30 @@
   languageName: node
   linkType: hard
 
-"@opentelemetry/instrumentation-amqplib@npm:^0.42.0":
-  version: 0.42.0
-  resolution: "@opentelemetry/instrumentation-amqplib@npm:0.42.0"
+"@opentelemetry/instrumentation-amqplib@npm:^0.43.0":
+  version: 0.43.0
+  resolution: "@opentelemetry/instrumentation-amqplib@npm:0.43.0"
   dependencies:
     "@opentelemetry/core": "npm:^1.8.0"
-    "@opentelemetry/instrumentation": "npm:^0.53.0"
+    "@opentelemetry/instrumentation": "npm:^0.54.0"
     "@opentelemetry/semantic-conventions": "npm:^1.27.0"
   peerDependencies:
     "@opentelemetry/api": ^1.3.0
-  checksum: 10c0/bdbcce51161f026ed7d57ae8694738655d1c1f1c1308570d28d85c6d42ed1cffedf2dac8dac0ab00a3fa820908525171086a265d5c366cd4a372517d87fbdff5
+  checksum: 10c0/76d0e22d2d2ac06e98474e5cc14dca4f35117bed14bf4f584a1f8a2bf3a91a448d5fd0c6ebebeb5102dba4962a3293b785e410429ccf952391e4f00f3602c5d1
   languageName: node
   linkType: hard
 
-"@opentelemetry/instrumentation-connect@npm:0.39.0":
-  version: 0.39.0
-  resolution: "@opentelemetry/instrumentation-connect@npm:0.39.0"
+"@opentelemetry/instrumentation-connect@npm:0.40.0":
+  version: 0.40.0
+  resolution: "@opentelemetry/instrumentation-connect@npm:0.40.0"
   dependencies:
     "@opentelemetry/core": "npm:^1.8.0"
-    "@opentelemetry/instrumentation": "npm:^0.53.0"
+    "@opentelemetry/instrumentation": "npm:^0.54.0"
     "@opentelemetry/semantic-conventions": "npm:^1.27.0"
     "@types/connect": "npm:3.4.36"
   peerDependencies:
     "@opentelemetry/api": ^1.3.0
-  checksum: 10c0/c137f64b32d2bf916c0e928428ece7313682c9e845052d1f3884e807dcc0417c7751577e04451200c8d49448789c197f459dbbaad3ccb3748342cdfd242b3b51
+  checksum: 10c0/675fe74aa93cbd2c446687c001c3a2ccaf7a1853aae5c7b840083b40b1f4922d91c6a0f2182e8374798e3c557d871351ffa1da123673ba535f6be0da802c15aa
   languageName: node
   linkType: hard
 
@@ -2707,41 +2716,41 @@
   languageName: node
   linkType: hard
 
-"@opentelemetry/instrumentation-express@npm:0.43.0":
-  version: 0.43.0
-  resolution: "@opentelemetry/instrumentation-express@npm:0.43.0"
+"@opentelemetry/instrumentation-express@npm:0.44.0":
+  version: 0.44.0
+  resolution: "@opentelemetry/instrumentation-express@npm:0.44.0"
   dependencies:
     "@opentelemetry/core": "npm:^1.8.0"
-    "@opentelemetry/instrumentation": "npm:^0.53.0"
+    "@opentelemetry/instrumentation": "npm:^0.54.0"
     "@opentelemetry/semantic-conventions": "npm:^1.27.0"
   peerDependencies:
     "@opentelemetry/api": ^1.3.0
-  checksum: 10c0/5b2e56e8c6c546103f8e9a69e632bb5b8d992da0a1858cb35f6320f98675df503b1b07a704559d11e29fe47366f98296729b0cccaa543debcfe2072888331b72
+  checksum: 10c0/9a6a20b8b3ab18f7751b443003691b720f63e4b1a17315486ce7ece81801c38920d4c42187cc96f70c902285b2ddcafe23d8c14cae749a537925eb8bca47dd1e
   languageName: node
   linkType: hard
 
-"@opentelemetry/instrumentation-fastify@npm:0.40.0":
-  version: 0.40.0
-  resolution: "@opentelemetry/instrumentation-fastify@npm:0.40.0"
+"@opentelemetry/instrumentation-fastify@npm:0.41.0":
+  version: 0.41.0
+  resolution: "@opentelemetry/instrumentation-fastify@npm:0.41.0"
   dependencies:
     "@opentelemetry/core": "npm:^1.8.0"
-    "@opentelemetry/instrumentation": "npm:^0.53.0"
+    "@opentelemetry/instrumentation": "npm:^0.54.0"
     "@opentelemetry/semantic-conventions": "npm:^1.27.0"
   peerDependencies:
     "@opentelemetry/api": ^1.3.0
-  checksum: 10c0/2b05562aa8433fae2343c015a7e3c23a3871aaab1a50ddfb8c0974b03c7a0693c27dc4014ebcde61ec53658fc84c4554d6ba1ed1c0212fbcf6423424c07ed1ca
+  checksum: 10c0/1f0fb411901d44becdb331f9a9834d1f25e6b734f6b32b8efc94d267d794cdecf1cf16fb419ee9562c8e91a4015eefc975fc472bb36b4a2f9708578263caf911
   languageName: node
   linkType: hard
 
-"@opentelemetry/instrumentation-fs@npm:0.15.0":
-  version: 0.15.0
-  resolution: "@opentelemetry/instrumentation-fs@npm:0.15.0"
+"@opentelemetry/instrumentation-fs@npm:0.16.0":
+  version: 0.16.0
+  resolution: "@opentelemetry/instrumentation-fs@npm:0.16.0"
   dependencies:
     "@opentelemetry/core": "npm:^1.8.0"
-    "@opentelemetry/instrumentation": "npm:^0.53.0"
+    "@opentelemetry/instrumentation": "npm:^0.54.0"
   peerDependencies:
     "@opentelemetry/api": ^1.3.0
-  checksum: 10c0/d06508e7c36fe9ed8db920f2481bcaafb5cc22d6f3d0c95dd97b098ca326a8b6089e2bf3b77c106f275ed3e019576e49c5b16036943e76675b1ce80a4d427a2b
+  checksum: 10c0/3975e12f24a59a9a5f1d7c9816aeb35d5f554756d46255acdbf210aceac2d63cbba3f3f56264fb07bd6ab9317586f872976ec3006f0bc4ed4bf6d20be23e3f51
   languageName: node
   linkType: hard
 
@@ -2756,14 +2765,14 @@
   languageName: node
   linkType: hard
 
-"@opentelemetry/instrumentation-graphql@npm:0.43.0":
-  version: 0.43.0
-  resolution: "@opentelemetry/instrumentation-graphql@npm:0.43.0"
+"@opentelemetry/instrumentation-graphql@npm:0.44.0":
+  version: 0.44.0
+  resolution: "@opentelemetry/instrumentation-graphql@npm:0.44.0"
   dependencies:
-    "@opentelemetry/instrumentation": "npm:^0.53.0"
+    "@opentelemetry/instrumentation": "npm:^0.54.0"
   peerDependencies:
     "@opentelemetry/api": ^1.3.0
-  checksum: 10c0/d1db48ea4af5f9352da5c644a04253908c4df1d386176ee2d2679a7f22769411a2ce10a53fd9910c11ea2d80307d0bd613ba64193b77329648e2e2da08edabf5
+  checksum: 10c0/9435cb6c7bf9c9b2d1c1da2c12e8017db3c25fbd29ba7d17b1f2b74417c2768f1b919c50558cbf2f6d9ab5d865efe55ce6104fe0a4e3a4e3346d4a8c8ffe04e1
   languageName: node
   linkType: hard
 
@@ -2807,15 +2816,27 @@
   languageName: node
   linkType: hard
 
-"@opentelemetry/instrumentation-kafkajs@npm:0.3.0":
-  version: 0.3.0
-  resolution: "@opentelemetry/instrumentation-kafkajs@npm:0.3.0"
+"@opentelemetry/instrumentation-kafkajs@npm:0.4.0":
+  version: 0.4.0
+  resolution: "@opentelemetry/instrumentation-kafkajs@npm:0.4.0"
+  dependencies:
+    "@opentelemetry/instrumentation": "npm:^0.54.0"
+    "@opentelemetry/semantic-conventions": "npm:^1.27.0"
+  peerDependencies:
+    "@opentelemetry/api": ^1.3.0
+  checksum: 10c0/617a6512f0837bb0e48c08404a7fdaff92e93a645b6780708553d4f3e873bfd4b9bd04b50b5d08edde6d1e61bc428966073ee06f947d3cbc4f4e6245788215c4
+  languageName: node
+  linkType: hard
+
+"@opentelemetry/instrumentation-knex@npm:0.41.0":
+  version: 0.41.0
+  resolution: "@opentelemetry/instrumentation-knex@npm:0.41.0"
   dependencies:
-    "@opentelemetry/instrumentation": "npm:^0.53.0"
+    "@opentelemetry/instrumentation": "npm:^0.54.0"
     "@opentelemetry/semantic-conventions": "npm:^1.27.0"
   peerDependencies:
     "@opentelemetry/api": ^1.3.0
-  checksum: 10c0/e29b0a0010a004418ada1277018aca316eb38de304afe7c5f5e56c60bbfd714fc7e8f0ddcd53c9a87233d1d31c57761292a0b1292496a08ccbfd954df0635a5b
+  checksum: 10c0/f9d1acdbbe83c428d4929dee468ed19ac758d86e99f6cf1481ee6f04cc4012c60a36f8d75875571c1e10dc486e995d26f2431ec70c37ed5effd78bec8b53ced1
   languageName: node
   linkType: hard
 
@@ -2843,16 +2864,15 @@
   languageName: node
   linkType: hard
 
-"@opentelemetry/instrumentation-mongodb@npm:0.47.0":
-  version: 0.47.0
-  resolution: "@opentelemetry/instrumentation-mongodb@npm:0.47.0"
+"@opentelemetry/instrumentation-mongodb@npm:0.48.0":
+  version: 0.48.0
+  resolution: "@opentelemetry/instrumentation-mongodb@npm:0.48.0"
   dependencies:
-    "@opentelemetry/instrumentation": "npm:^0.53.0"
-    "@opentelemetry/sdk-metrics": "npm:^1.9.1"
+    "@opentelemetry/instrumentation": "npm:^0.54.0"
     "@opentelemetry/semantic-conventions": "npm:^1.27.0"
   peerDependencies:
     "@opentelemetry/api": ^1.3.0
-  checksum: 10c0/aa3238c3fd4d8f58bb22255051b4203ca6fb2d6e45ef16fc6c3e34bd79230e9faa3f4753b5c1dbc154d50f4be832107623781ab070c63c5ae46713d0e1a65e45
+  checksum: 10c0/dc4bbc17143518810952968be21c28b9a5017ce75eeb75023d935e40094bc4d041bdf77997fd96a24cfdc05c5f0deaf631623c2843f812a2e647bf62c6321bd2
   languageName: node
   linkType: hard
 
@@ -2934,6 +2954,19 @@
   checksum: 10c0/4bb5408daeefc10395443fd10bd2b933c88f18658f181bd80c240f49e896c14bb520b71f2eca31fa27a4f1d82448ffceb88c2ee419eec1041f997f8a1d9a6818
   languageName: node
   linkType: hard
+
+"@opentelemetry/instrumentation-tedious@npm:0.15.0":
+  version: 0.15.0
+  resolution: "@opentelemetry/instrumentation-tedious@npm:0.15.0"
+  dependencies:
+    "@opentelemetry/instrumentation": "npm:^0.54.0"
+    "@opentelemetry/semantic-conventions": "npm:^1.27.0"
+    "@types/tedious": "npm:^4.0.14"
+  peerDependencies:
+    "@opentelemetry/api": ^1.3.0
+  checksum: 10c0/2e1e86497a09511dd1271968ca5610008a985901076d17252e3c27875a85253394bea9b24387a913babfca15c54523b00ddcde2d252c7a5cc8d5952676c82ce7
+  languageName: node
+  linkType: hard
 
 "@opentelemetry/instrumentation-undici@npm:0.6.0":
   version: 0.6.0
@@ -2978,6 +3011,22 @@
   checksum: 10c0/1d4946b470ac31358ba8d81a9f9653a1d705db96ffb8958fef873340c3d3c9699cfd8ff617c313ea8c6a8ece51aa7cf8af37d87a60813c31ed2207e5c14a33ba
   languageName: node
   linkType: hard
+
+"@opentelemetry/instrumentation@npm:^0.54.0":
+  version: 0.54.2
+  resolution: "@opentelemetry/instrumentation@npm:0.54.2"
+  dependencies:
+    "@opentelemetry/api-logs": "npm:0.54.2"
+    "@types/shimmer": "npm:^1.2.0"
+    import-in-the-middle: "npm:^1.8.1"
+    require-in-the-middle: "npm:^7.1.1"
+    semver: "npm:^7.5.2"
+    shimmer: "npm:^1.2.1"
+  peerDependencies:
+    "@opentelemetry/api": ^1.3.0
+  checksum: 10c0/78e80ea33b14988806d8fdc7603123c18680dd03e7038521bb72de4d67bbbca17569244cfdfd97c7646f430a361cf9c04db086d4a2b5c635b81b6a7c8b04806f
+  languageName: node
+  linkType: hard
 
 "@opentelemetry/redis-common@npm:^0.36.2":
   version: 0.36.2
@@ -2998,18 +3047,6 @@
   languageName: node
   linkType: hard
 
-"@opentelemetry/sdk-metrics@npm:^1.9.1":
-  version: 1.26.0
-  resolution: "@opentelemetry/sdk-metrics@npm:1.26.0"
-  dependencies:
-    "@opentelemetry/core": "npm:1.26.0"
-    "@opentelemetry/resources": "npm:1.26.0"
-  peerDependencies:
-    "@opentelemetry/api": ">=1.3.0 <1.10.0"
-  checksum: 10c0/640a0dcfa4af73a029ef57b51f8ecc1d08dfb0c3a5242552876fab36c7f9ae7c410fa52dbc5202a2d8675fcfe61df3c49205079963f1c11acfe42981d1d01a76
-  languageName: node
-  linkType: hard
-
 "@opentelemetry/sdk-trace-base@npm:^1.22, @opentelemetry/sdk-trace-base@npm:^1.26.0":
   version: 1.26.0
   resolution: "@opentelemetry/sdk-trace-base@npm:1.26.0"
@@ -3504,104 +3541,106 @@
   languageName: node
   linkType: hard
 
-"@sentry/core@npm:8.35.0":
-  version: 8.35.0
-  resolution: "@sentry/core@npm:8.35.0"
+"@sentry/core@npm:8.38.0":
+  version: 8.38.0
+  resolution: "@sentry/core@npm:8.38.0"
   dependencies:
-    "@sentry/types": "npm:8.35.0"
-    "@sentry/utils": "npm:8.35.0"
-  checksum: 10c0/93f2dd5a08484712d895b110f7f4c364e7cf43aef770a05e089584ec4decf95fac5a6fe255714aa216f1f2ac65b38306138307f9a84235a3090659fa53e4c074
+    "@sentry/types": "npm:8.38.0"
+    "@sentry/utils": "npm:8.38.0"
+  checksum: 10c0/247b346f34ae4d9682daa1438a29193e66c9a0ec892b3ec5edc8fcabb96409edeaa7f9637e32eede457d45af7ed4b83a155b6daa5eab4b54790d5ad79e2268c8
   languageName: node
   linkType: hard
 
-"@sentry/nestjs@npm:^8.35.0":
-  version: 8.35.0
-  resolution: "@sentry/nestjs@npm:8.35.0"
+"@sentry/nestjs@npm:8.38.0":
+  version: 8.38.0
+  resolution: "@sentry/nestjs@npm:8.38.0"
   dependencies:
-    "@sentry/core": "npm:8.35.0"
-    "@sentry/node": "npm:8.35.0"
-    "@sentry/types": "npm:8.35.0"
-    "@sentry/utils": "npm:8.35.0"
+    "@sentry/core": "npm:8.38.0"
+    "@sentry/node": "npm:8.38.0"
+    "@sentry/types": "npm:8.38.0"
+    "@sentry/utils": "npm:8.38.0"
   peerDependencies:
     "@nestjs/common": ^8.0.0 || ^9.0.0 || ^10.0.0
     "@nestjs/core": ^8.0.0 || ^9.0.0 || ^10.0.0
-  checksum: 10c0/e2ee4a06942101b550d94961643a1c64131b8a2a2e249431301d81715ab3ccb083912b3ed2b62f567fb9353e5656b20fa7ae12bb20a539336a76726fb7ad6692
+  checksum: 10c0/438c07af195714c8ef7987560c6430219fe6eccaa05782028ed85deec007a14e12e241e36e34cccd17be2766ac97ee8b8da795d3eb27713bd6d1b2a136bc1dc1
   languageName: node
   linkType: hard
 
-"@sentry/node@npm:8.35.0":
-  version: 8.35.0
-  resolution: "@sentry/node@npm:8.35.0"
+"@sentry/node@npm:8.38.0":
+  version: 8.38.0
+  resolution: "@sentry/node@npm:8.38.0"
   dependencies:
     "@opentelemetry/api": "npm:^1.9.0"
     "@opentelemetry/context-async-hooks": "npm:^1.25.1"
     "@opentelemetry/core": "npm:^1.25.1"
-    "@opentelemetry/instrumentation": "npm:^0.53.0"
-    "@opentelemetry/instrumentation-amqplib": "npm:^0.42.0"
-    "@opentelemetry/instrumentation-connect": "npm:0.39.0"
+    "@opentelemetry/instrumentation": "npm:^0.54.0"
+    "@opentelemetry/instrumentation-amqplib": "npm:^0.43.0"
+    "@opentelemetry/instrumentation-connect": "npm:0.40.0"
     "@opentelemetry/instrumentation-dataloader": "npm:0.12.0"
-    "@opentelemetry/instrumentation-express": "npm:0.43.0"
-    "@opentelemetry/instrumentation-fastify": "npm:0.40.0"
-    "@opentelemetry/instrumentation-fs": "npm:0.15.0"
+    "@opentelemetry/instrumentation-express": "npm:0.44.0"
+    "@opentelemetry/instrumentation-fastify": "npm:0.41.0"
+    "@opentelemetry/instrumentation-fs": "npm:0.16.0"
     "@opentelemetry/instrumentation-generic-pool": "npm:0.39.0"
-    "@opentelemetry/instrumentation-graphql": "npm:0.43.0"
+    "@opentelemetry/instrumentation-graphql": "npm:0.44.0"
     "@opentelemetry/instrumentation-hapi": "npm:0.41.0"
     "@opentelemetry/instrumentation-http": "npm:0.53.0"
     "@opentelemetry/instrumentation-ioredis": "npm:0.43.0"
-    "@opentelemetry/instrumentation-kafkajs": "npm:0.3.0"
+    "@opentelemetry/instrumentation-kafkajs": "npm:0.4.0"
+    "@opentelemetry/instrumentation-knex": "npm:0.41.0"
     "@opentelemetry/instrumentation-koa": "npm:0.43.0"
     "@opentelemetry/instrumentation-lru-memoizer": "npm:0.40.0"
-    "@opentelemetry/instrumentation-mongodb": "npm:0.47.0"
+    "@opentelemetry/instrumentation-mongodb": "npm:0.48.0"
     "@opentelemetry/instrumentation-mongoose": "npm:0.42.0"
     "@opentelemetry/instrumentation-mysql": "npm:0.41.0"
     "@opentelemetry/instrumentation-mysql2": "npm:0.41.0"
     "@opentelemetry/instrumentation-nestjs-core": "npm:0.40.0"
     "@opentelemetry/instrumentation-pg": "npm:0.44.0"
     "@opentelemetry/instrumentation-redis-4": "npm:0.42.0"
+    "@opentelemetry/instrumentation-tedious": "npm:0.15.0"
     "@opentelemetry/instrumentation-undici": "npm:0.6.0"
     "@opentelemetry/resources": "npm:^1.26.0"
     "@opentelemetry/sdk-trace-base": "npm:^1.26.0"
     "@opentelemetry/semantic-conventions": "npm:^1.27.0"
     "@prisma/instrumentation": "npm:5.19.1"
-    "@sentry/core": "npm:8.35.0"
-    "@sentry/opentelemetry": "npm:8.35.0"
-    "@sentry/types": "npm:8.35.0"
-    "@sentry/utils": "npm:8.35.0"
+    "@sentry/core": "npm:8.38.0"
+    "@sentry/opentelemetry": "npm:8.38.0"
+    "@sentry/types": "npm:8.38.0"
+    "@sentry/utils": "npm:8.38.0"
     import-in-the-middle: "npm:^1.11.2"
-  checksum: 10c0/cd5baa72209a8f78f3c25ee132cebf3d55b58e6faed1c3f83826796b722a7083504ce037ab886e50861ea5d1a861de6c494bfa1e44baffbb564fa47932939990
+  checksum: 10c0/99e4a6049417a80e5d26ccbb0da48b40caaa66744764e9985fc3e341847f3699d6b7e9710adb421b10cec70056aab2513170a450acec29a25ba5aac607421f5f
   languageName: node
   linkType: hard
 
-"@sentry/opentelemetry@npm:8.35.0":
-  version: 8.35.0
-  resolution: "@sentry/opentelemetry@npm:8.35.0"
+"@sentry/opentelemetry@npm:8.38.0":
+  version: 8.38.0
+  resolution: "@sentry/opentelemetry@npm:8.38.0"
   dependencies:
-    "@sentry/core": "npm:8.35.0"
-    "@sentry/types": "npm:8.35.0"
-    "@sentry/utils": "npm:8.35.0"
+    "@sentry/core": "npm:8.38.0"
+    "@sentry/types": "npm:8.38.0"
+    "@sentry/utils": "npm:8.38.0"
   peerDependencies:
     "@opentelemetry/api": ^1.9.0
     "@opentelemetry/core": ^1.25.1
-    "@opentelemetry/instrumentation": ^0.53.0
+    "@opentelemetry/instrumentation": ^0.54.0
     "@opentelemetry/sdk-trace-base": ^1.26.0
     "@opentelemetry/semantic-conventions": ^1.27.0
-  checksum: 10c0/cbf311abdef13c5114d7be7bddaae7e92111e6ad6e3d0744c32096399fecdc493eae1788c8222ba9f5000a49f57d8b608671cc98c36af29679a6328c1757b919
+  checksum: 10c0/5f06f29156bc15c6343f7a855fbdd857eb12df275571361b801ccaea8f0a37e0201e2c8d9ee288e6c4ff543f0efbee242580fdde69f0a1f9ff7d013e09c252d4
   languageName: node
   linkType: hard
 
-"@sentry/types@npm:8.35.0":
-  version: 8.35.0
-  resolution: "@sentry/types@npm:8.35.0"
-  checksum: 10c0/b28d87ef26d1b889cf7c951a697caf70d9092d84dd1ae777700a0a009da832a8a5c298632dba62fbcb1a3252d011353068c64419e8e952b676f20deca8d03d64
+"@sentry/types@npm:8.38.0":
+  version: 8.38.0
+  resolution: "@sentry/types@npm:8.38.0"
+  checksum: 10c0/615ee4d8732cefc74eb19330662eae297321a992f080efff1f15bf2957c72d211240b17ea8712bbbe88da5b29c1604efa4166ef51e745ebef58609290ef72bfe
   languageName: node
   linkType: hard
 
-"@sentry/utils@npm:8.35.0":
-  version: 8.35.0
-  resolution: "@sentry/utils@npm:8.35.0"
+"@sentry/utils@npm:8.38.0":
+  version: 8.38.0
+  resolution: "@sentry/utils@npm:8.38.0"
   dependencies:
-    "@sentry/types": "npm:8.35.0"
-  checksum: 10c0/5c1178f0000165d6436d98902bc4107fcdae9aa84c23458b4c6b1a89b4734185292fb776427d6ec8e174e7e6c1c32b7c72585bb3ddd3ddd893dd8e5884c50d67
+    "@sentry/types": "npm:8.38.0"
+  checksum: 10c0/01baeb95a355916502f1d8390f5398bb1a59dbda417e21a9170c4a4b1e2eb05029d2044fd82c6666338a1d497212570a36db92c1e3604a3fcd71bcf9d62451ca
   languageName: node
   linkType: hard
 
@@ -4837,6 +4876,15 @@
   languageName: node
   linkType: hard
 
+"@types/tedious@npm:^4.0.14":
+  version: 4.0.14
+  resolution: "@types/tedious@npm:4.0.14"
+  dependencies:
+    "@types/node": "npm:*"
+  checksum: 10c0/d2914f8e9b5b998e4275ec5f0130cba1c2fb47e75616b5c125a65ef6c1db2f1dc3f978c7900693856a15d72bbb4f4e94f805537a4ecb6dc126c64415d31c0590
+  languageName: node
+  linkType: hard
+
 "@types/tough-cookie@npm:*":
   version: 4.0.5
   resolution: "@types/tough-cookie@npm:4.0.5"
@@ -9563,7 +9611,7 @@
     "@prisma/client": "npm:5.22.0"
     "@quramy/prisma-fabbrica": "npm:^2.2.1"
     "@sentry/cli": "npm:^2.38.0"
-    "@sentry/nestjs": "npm:^8.35.0"
+    "@sentry/nestjs": "npm:8.38.0"
     "@sesamecare-oss/redlock": "npm:^1.3.1"
     "@snaplet/copycat": "npm:^5.1.0"
     "@swc-node/register": "npm:^1.10.9"

My instrument.ts, imported second in the main.ts is pretty basic:

import * as Sentry from '@sentry/nestjs';
import { AppConfig } from '../config/config';

const dsn = AppConfig.sentry.dsn;
Sentry.init({
  enabled: !!dsn,
  dsn: dsn,
  environment: new URL(AppConfig.backendUrl).hostname,
  tracesSampleRate: Number(AppConfig.sentry.tracesSampleRate),
  includeLocalVariables: false,
  integrations: [
    Sentry.extraErrorDataIntegration(),
    Sentry.prismaIntegration(),
  ],
  ignoreTransactions: ['GET /health', 'prisma:client:operation'],
  normalizeDepth: 5,
  ignoreErrors: ['auth/id-token-expired'],
});

I'll try commenting out the Sentry.init() call, but I don't think it will change something. I believe it's the requires that take too long.

@getsantry getsantry bot moved this to Waiting for: Product Owner in GitHub Issues with 👀 3 Nov 21, 2024
@wodCZ
Copy link

wodCZ commented Nov 21, 2024

Huh, commenting out Sentry.init() and replacing it with console.log(Sentry.SDK_VERSION); did have effect.

The container started with this log:

2024-11-21T14:53:59.202535603Z stdout F [2024-11-21T14:53:59Z INFO ] Starting container entrypoint...
2024-11-21T14:54:13.218139375Z stdout F 8.38.0
2024-11-21T14:54:37.443307746Z stdout F Imports time: 37.123s
2024-11-21T14:54:37.444337241Z stdout F Module load times:
2024-11-21T14:54:37.613544224Z stdout F @sentry: 25206.22 ms
2024-11-21T14:54:37.619229322Z stdout F @opentelemetry: 11323.59 ms
2024-11-21T14:54:37.619254101Z stdout F @nestjs: 10150.49 ms
2024-11-21T14:54:37.6192568Z stdout F @aws-sdk: 3032.03 ms
2024-11-21T14:54:37.619259033Z stdout F pdfkit: 2194.13 ms
2024-11-21T14:54:37.619260965Z stdout F class-validator: 2190.51 ms
2024-11-21T14:54:37.619262878Z stdout F fontkit: 1875.26 ms
2024-11-21T14:54:37.619264965Z stdout F @smithy: 1847.56 ms
2024-11-21T14:54:37.619266788Z stdout F @fastify: 1825.67 ms

@andreiborza
Copy link
Member

@wodCZ thanks for providing so much context!

Could you try filtering out all the integrations and see if that changes anything?

integrations: function () {
   return [];
},

@wodCZ
Copy link

wodCZ commented Nov 21, 2024

@andreiborza that worked, started fine:

2024-11-21T15:20:38.746495876Z stdout F [2024-11-21T15:20:38Z INFO ] Starting container entrypoint...
2024-11-21T15:21:19.221067527Z stdout F Imports time: 39.215s
2024-11-21T15:21:19.221909691Z stdout F Module load times:
2024-11-21T15:21:19.222694466Z stdout F @sentry: 20923.13 ms
2024-11-21T15:21:19.222712295Z stdout F @opentelemetry: 13975.16 ms
2024-11-21T15:21:19.222716045Z stdout F @nestjs: 11341.76 ms
2024-11-21T15:21:19.222719056Z stdout F @aws-sdk: 4079.97 ms
2024-11-21T15:21:19.222721878Z stdout F class-validator: 2720.28 ms
2024-11-21T15:21:19.222724665Z stdout F firebase-admin: 2493.80 ms
2024-11-21T15:21:19.2227275Z stdout F pdfkit: 2081.41 ms
2024-11-21T15:21:19.227502432Z stdout F @smithy: 2002.44 ms
2024-11-21T15:21:19.227532907Z stdout F rxjs: 1899.01 ms
2024-11-21T15:21:19.227538127Z stdout F fontkit: 1691.94 ms
2024-11-21T15:21:19.227541075Z stdout F bentocache: 1687.93 ms
2024-11-21T15:21:19.2275441Z stdout F @fastify: 1585.66 ms

@getsantry getsantry bot moved this to Waiting for: Product Owner in GitHub Issues with 👀 3 Nov 21, 2024
@wodCZ
Copy link

wodCZ commented Nov 21, 2024

And this is with integrations omitted, barely making it, eventually rebooting and failing:

2024-11-21T15:27:11.456765016Z stdout F [2024-11-21T15:27:11Z INFO ] Starting container entrypoint...
2024-11-21T15:29:52.652527646Z stdout F Imports time: 2:40.098 (m:ss.mmm)
2024-11-21T15:29:52.65311951Z stdout F Module load times:
2024-11-21T15:29:52.654194129Z stdout F @nestjs: 67381.20 ms
2024-11-21T15:29:52.654628639Z stdout F @sentry: 17374.49 ms
2024-11-21T15:29:52.654658066Z stdout F class-validator: 14593.63 ms
2024-11-21T15:29:52.654660815Z stdout F rxjs: 13410.37 ms
2024-11-21T15:29:52.654662809Z stdout F @aws-sdk: 13024.35 ms
2024-11-21T15:29:52.654664875Z stdout F firebase-admin: 12378.19 ms
2024-11-21T15:29:52.655054583Z stdout F @fastify: 10974.04 ms
2024-11-21T15:29:52.655411384Z stdout F pdfkit: 10687.25 ms
2024-11-21T15:29:52.655675648Z stdout F fastify: 10487.34 ms
2024-11-21T15:29:52.655685612Z stdout F @opentelemetry: 9637.38 ms
2024-11-21T15:29:52.655688785Z stdout F fontkit: 8885.36 ms
2024-11-21T15:29:52.655978577Z stdout F mercurius: 6896.28 ms
2024-11-21T15:29:52.656003292Z stdout F @smithy: 6635.25 ms
2024-11-21T15:29:52.656007559Z stdout F bull: 6513.20 ms

@andreiborza
Copy link
Member

@wodCZ right so your hunch with it being related to the Otel bumps might to be correct. Hm...

Could you try disabling integration after integration and comparing times?

First print out the integrations array in the integrations filtering function to get the list of all loaded integrations and then filter them out one after another like this:

integrations: (integrations) => {
    reutrn integrations.filter(integration =>
      integration.name !== "InboundFilters" &&
      integration.name !== 'FunctionToString' && 
      ...
    )
  },

@wodCZ
Copy link

wodCZ commented Nov 21, 2024

And this is with 8.36.0 with default integrations. Close to 8.35.0.

2024-11-21T15:38:52.238116013Z stdout F [2024-11-21T15:38:52Z INFO ] Starting container entrypoint...
2024-11-21T15:40:19.655555371Z stdout F Imports time: 1:26.401 (m:ss.mmm)
2024-11-21T15:40:19.656386218Z stdout F Module load times:
2024-11-21T15:40:19.656917678Z stdout F @nestjs: 33306.23 ms
2024-11-21T15:40:19.656947099Z stdout F @sentry: 14588.93 ms
2024-11-21T15:40:19.656952546Z stdout F class-validator: 7706.32 ms
2024-11-21T15:40:19.657497292Z stdout F @opentelemetry: 7114.82 ms
2024-11-21T15:40:19.657517887Z stdout F firebase-admin: 6937.34 ms
2024-11-21T15:40:19.657523351Z stdout F @aws-sdk: 6910.63 ms
2024-11-21T15:40:19.658220132Z stdout F rxjs: 6487.34 ms
2024-11-21T15:40:19.659280697Z stdout F pdfkit: 6212.15 ms
2024-11-21T15:40:19.659297752Z stdout F fontkit: 4990.07 ms
2024-11-21T15:40:19.659301174Z stdout F fastify: 4710.12 ms
2024-11-21T15:40:19.65930408Z stdout F @fastify: 4511.00 ms
2024-11-21T15:40:19.659307159Z stdout F @smithy: 3851.15 ms
2024-11-21T15:40:19.659315059Z stdout F bull: 3110.83 ms
2024-11-21T15:40:19.660095595Z stdout F mercurius: 3002.92 ms

Unfortunately, filtering them one by one would take ages, since the difference is hardly reproducible on M1 CPU/MB Pro. I had to do the whole deploy process after each change, which takes 10-15 minutes.

I'm done for today, reverting to .35.

@getsantry getsantry bot moved this to Waiting for: Product Owner in GitHub Issues with 👀 3 Nov 21, 2024
@andreiborza
Copy link
Member

@wodCZ understood. Thanks again for all the investigative work. Sorry about having to revert, we'll try to look into it some more.

@dhenneke
Copy link

We noticed this problem when using @sentry/node in our firebase functions. The startup time jumped by factor of ~10 to over 30 seconds. It started getting slower in 8.36.0 and got worse until 8.40.0. We rolled back to 8.35.0 to fix the performance issues.

I tested leaving out selected integrations and went to deploy and run 31 different functions which where each function will add one additional integration. It's also build in a way that all these calls are cold starts. Maybe this helps debugging the issue.

This is the result (AccessRights is a module that imports a lot of other dependencies):

  • First big jump: 839ms -> 4.999s adding Http
  • Afterwards it's more or less linearly rising, with some variance in between. In the end it's 17 seconds.
  • The total runtime with also the execution rises from ~6 seconds to ~30 seconds.
Detail logs
Integrations: []
IMPORT AccessRights: 633.776ms

Integrations: [ 'InboundFilters' ]
IMPORT AccessRights: 756.996ms

Integrations: [ 'InboundFilters', 'FunctionToString' ]
IMPORT AccessRights: 415.16ms

Integrations: [ 'InboundFilters', 'FunctionToString', 'LinkedErrors' ]
IMPORT AccessRights: 420.312ms

Integrations: [ 'InboundFilters', 'FunctionToString', 'LinkedErrors', 'RequestData' ]
IMPORT AccessRights: 678.431ms

"Integrations: [ 'InboundFilters', 'FunctionToString', 'LinkedErrors', 'RequestData', 'Console' ]"
IMPORT AccessRights: 839.744ms

"Integrations: [ 'InboundFilters','FunctionToString','LinkedErrors','RequestData','Console','Http' ]"
IMPORT AccessRights: 4.999s

"Integrations: [ 'InboundFilters', 'FunctionToString', 'LinkedErrors', 'RequestData', 'Console', 'Http', 'NodeFetch' ]"
IMPORT AccessRights: 7.229s

"Integrations: [ 'InboundFilters', 'FunctionToString', 'LinkedErrors', 'RequestData', 'Console', 'Http', 'NodeFetch', 'OnUncaughtException' ]"
IMPORT AccessRights: 7.396s

"Integrations: [ 'InboundFilters', 'FunctionToString', 'LinkedErrors', 'RequestData', 'Console', 'Http', 'NodeFetch', 'OnUncaughtException', 'OnUnhandledRejection' ]"
IMPORT AccessRights: 7.019s

"Integrations: [ 'InboundFilters', 'FunctionToString', 'LinkedErrors', 'RequestData', 'Console', 'Http', 'NodeFetch', 'OnUncaughtException', 'OnUnhandledRejection', 'ContextLines' ]"
IMPORT AccessRights: 7.187s

"Integrations: [ 'InboundFilters', 'FunctionToString', 'LinkedErrors', 'RequestData', 'Console', 'Http', 'NodeFetch', 'OnUncaughtException', 'OnUnhandledRejection', 'ContextLines', 'LocalVariables' ]"
IMPORT AccessRights: 6.921s

"Integrations: [ 'InboundFilters', 'FunctionToString', 'LinkedErrors', 'RequestData', 'Console', 'Http', 'NodeFetch', 'OnUncaughtException', 'OnUnhandledRejection', 'ContextLines', 'LocalVariables', 'Context' ]"
IMPORT AccessRights: 7.579s

"Integrations: [ 'InboundFilters', 'FunctionToString', 'LinkedErrors', 'RequestData', 'Console', 'Http', 'NodeFetch', 'OnUncaughtException', 'OnUnhandledRejection', 'ContextLines', 'LocalVariables', 'Context', 'ProcessAndThreadBreadcrumbs' ]"
IMPORT AccessRights: 7.601s

"Integrations: [ 'InboundFilters', 'FunctionToString', 'LinkedErrors', 'RequestData', 'Console', 'Http', 'NodeFetch', 'OnUncaughtException', 'OnUnhandledRejection', 'ContextLines', 'LocalVariables', 'Context', 'ProcessAndThreadBreadcrumbs', 'Modules' ]"
IMPORT AccessRights: 7.093s

"Integrations: [ 'InboundFilters', 'FunctionToString', 'LinkedErrors', 'RequestData', 'Console', 'Http', 'NodeFetch', 'OnUncaughtException', 'OnUnhandledRejection', 'ContextLines', 'LocalVariables', 'Context', 'ProcessAndThreadBreadcrumbs', 'Modules', 'Express' ]"
IMPORT AccessRights: 7.947s

"Integrations: [ 'InboundFilters', 'FunctionToString', 'LinkedErrors', 'RequestData', 'Console', 'Http', 'NodeFetch', 'OnUncaughtException', 'OnUnhandledRejection', 'ContextLines', 'LocalVariables', 'Context', 'ProcessAndThreadBreadcrumbs', 'Modules', 'Express', 'Fastify' ]"
IMPORT AccessRights: 7.199s

"Integrations: [ 'InboundFilters', 'FunctionToString', 'LinkedErrors', 'RequestData', 'Console', 'Http', 'NodeFetch', 'OnUncaughtException', 'OnUnhandledRejection', 'ContextLines', 'LocalVariables', 'Context', 'ProcessAndThreadBreadcrumbs', 'Modules', 'Express', 'Fastify', 'Graphql' ]"
IMPORT AccessRights: 4.351s

"Integrations: [ 'InboundFilters', 'FunctionToString', 'LinkedErrors', 'RequestData', 'Console', 'Http', 'NodeFetch', 'OnUncaughtException', 'OnUnhandledRejection', 'ContextLines', 'LocalVariables', 'Context', 'ProcessAndThreadBreadcrumbs', 'Modules', 'Express', 'Fastify', 'Graphql', 'Mongo']"
IMPORT AccessRights: 5.150s

"Integrations: [ 'InboundFilters', 'FunctionToString', 'LinkedErrors', 'RequestData', 'Console', 'Http', 'NodeFetch', 'OnUncaughtException', 'OnUnhandledRejection', 'ContextLines', 'LocalVariables', 'Context', 'ProcessAndThreadBreadcrumbs', 'Modules', 'Express', 'Fastify', 'Graphql', 'Mongo', 'Mongoose' ]"
IMPORT AccessRights: 6.134s

"Integrations: [ 'InboundFilters', 'FunctionToString', 'LinkedErrors', 'RequestData', 'Console', 'Http', 'NodeFetch', 'OnUncaughtException', 'OnUnhandledRejection', 'ContextLines', 'LocalVariables', 'Context', 'ProcessAndThreadBreadcrumbs', 'Modules', 'Express', 'Fastify', 'Graphql', 'Mongo', 'Mongoose', 'Mysql' ]"
IMPORT AccessRights: 6.756s

"Integrations: [ 'InboundFilters', 'FunctionToString', 'LinkedErrors', 'RequestData', 'Console', 'Http', 'NodeFetch', 'OnUncaughtException', 'OnUnhandledRejection', 'ContextLines', 'LocalVariables', 'Context', 'ProcessAndThreadBreadcrumbs', 'Modules', 'Express', 'Fastify', 'Graphql', 'Mongo', 'Mongoose', 'Mysql', 'Mysql2' ]"
IMPORT AccessRights: 9.760s

"Integrations: [ 'InboundFilters', 'FunctionToString', 'LinkedErrors', 'RequestData', 'Console', 'Http', 'NodeFetch', 'OnUncaughtException', 'OnUnhandledRejection', 'ContextLines', 'LocalVariables', 'Context', 'ProcessAndThreadBreadcrumbs', 'Modules', 'Express', 'Fastify', 'Graphql', 'Mongo', 'Mongoose', 'Mysql', 'Mysql2', 'Redis' ]"
IMPORT AccessRights: 11.830s

"Integrations: [ 'InboundFilters', 'FunctionToString', 'LinkedErrors', 'RequestData', 'Console', 'Http', 'NodeFetch', 'OnUncaughtException', 'OnUnhandledRejection', 'ContextLines', 'LocalVariables', 'Context', 'ProcessAndThreadBreadcrumbs', 'Modules', 'Express', 'Fastify', 'Graphql', 'Mongo', 'Mongoose', 'Mysql', 'Mysql2', 'Redis', 'Postgres' ]"
IMPORT AccessRights: 12.447s

"Integrations: [ 'InboundFilters', 'FunctionToString', 'LinkedErrors', 'RequestData', 'Console', 'Http', 'NodeFetch', 'OnUncaughtException', 'OnUnhandledRejection', 'ContextLines', 'LocalVariables', 'Context', 'ProcessAndThreadBreadcrumbs', 'Modules', 'Express', 'Fastify', 'Graphql', 'Mongo', 'Mongoose', 'Mysql', 'Mysql2', 'Redis', 'Postgres', 'Nest' ]"
IMPORT AccessRights: 14.649s

"Integrations: [ 'InboundFilters', 'FunctionToString', 'LinkedErrors', 'RequestData', 'Console', 'Http', 'NodeFetch', 'OnUncaughtException', 'OnUnhandledRejection', 'ContextLines', 'LocalVariables', 'Context', 'ProcessAndThreadBreadcrumbs', 'Modules', 'Express', 'Fastify', 'Graphql', 'Mongo', 'Mongoose', 'Mysql', 'Mysql2', 'Redis', 'Postgres', 'Nest', 'Hapi' ]"
IMPORT AccessRights: 15.912s

"Integrations: [ 'InboundFilters', 'FunctionToString', 'LinkedErrors', 'RequestData', 'Console', 'Http', 'NodeFetch', 'OnUncaughtException', 'OnUnhandledRejection', 'ContextLines', 'LocalVariables', 'Context', 'ProcessAndThreadBreadcrumbs', 'Modules', 'Express', 'Fastify', 'Graphql', 'Mongo', 'Mongoose', 'Mysql', 'Mysql2', 'Redis', 'Postgres', 'Nest', 'Hapi', 'Koa' ]"
IMPORT AccessRights: 17.745s

"Integrations: [ 'InboundFilters', 'FunctionToString', 'LinkedErrors', 'RequestData', 'Console', 'Http', 'NodeFetch', 'OnUncaughtException', 'OnUnhandledRejection', 'ContextLines', 'LocalVariables', 'Context', 'ProcessAndThreadBreadcrumbs', 'Modules', 'Express', 'Fastify', 'Graphql', 'Mongo', 'Mongoose', 'Mysql', 'Mysql2', 'Redis', 'Postgres', 'Nest', 'Hapi', 'Koa', 'Connect' ]"
IMPORT AccessRights: 17.014s

"Integrations: [ 'InboundFilters', 'FunctionToString', 'LinkedErrors', 'RequestData', 'Console', 'Http', 'NodeFetch', 'OnUncaughtException', 'OnUnhandledRejection', 'ContextLines', 'LocalVariables', 'Context', 'ProcessAndThreadBreadcrumbs', 'Modules', 'Express', 'Fastify', 'Graphql', 'Mongo', 'Mongoose', 'Mysql', 'Mysql2', 'Redis', 'Postgres', 'Nest', 'Hapi', 'Koa', 'Connect', 'Tedious' ]"
IMPORT AccessRights: 17.262s

"Integrations: [ 'InboundFilters', 'FunctionToString', 'LinkedErrors', 'RequestData', 'Console', 'Http', 'NodeFetch', 'OnUncaughtException', 'OnUnhandledRejection', 'ContextLines', 'LocalVariables', 'Context', 'ProcessAndThreadBreadcrumbs', 'Modules', 'Express', 'Fastify', 'Graphql', 'Mongo', 'Mongoose', 'Mysql', 'Mysql2', 'Redis', 'Postgres', 'Nest', 'Hapi', 'Koa', 'Connect', 'Tedious', 'GenericPool' ]"
IMPORT AccessRights: 18.844s

"Integrations: [ 'InboundFilters', 'FunctionToString', 'LinkedErrors', 'RequestData', 'Console', 'Http', 'NodeFetch', 'OnUncaughtException', 'OnUnhandledRejection', 'ContextLines', 'LocalVariables', 'Context', 'ProcessAndThreadBreadcrumbs', 'Modules', 'Express', 'Fastify', 'Graphql', 'Mongo', 'Mongoose', 'Mysql', 'Mysql2', 'Redis', 'Postgres', 'Nest', 'Hapi', 'Koa', 'Connect', 'Tedious', 'GenericPool', 'Kafka' ]"
IMPORT AccessRights: 18.062s

"Integrations: [ 'InboundFilters', 'FunctionToString', 'LinkedErrors', 'RequestData', 'Console', 'Http', 'NodeFetch', 'OnUncaughtException', 'OnUnhandledRejection', 'ContextLines', 'LocalVariables', 'Context', 'ProcessAndThreadBreadcrumbs', 'Modules', 'Express', 'Fastify', 'Graphql', 'Mongo', 'Mongoose', 'Mysql', 'Mysql2', 'Redis', 'Postgres', 'Nest', 'Hapi', 'Koa', 'Connect', 'Tedious', 'GenericPool', 'Kafka', 'Amqplib' ]"
IMPORT AccessRights: 17.340s

This is the dependencies array of our packages.json:

package.json
"dependencies": [
    "@sentry/node": "8.40.0",
    "blob-stream": "^0.1.3",
    "currency.js": "^2.0.4",
    "date-fns": "^4.1.0",
    "dotenv": "^16.4.5",
    "dotenv-expand": "^11.0.6",
    "filenamify": "^4.3.0",
    "firebase-admin": "^12.7.0",
    "firebase-functions": "^6.1.0",
    "fp-ts": "^2.16.6",
    "html-to-pdfmake": "^2.5.6",
    "i18next": "^23.16.4",
    "i18next-resources-to-backend": "^1.2.1",
    "io-ts": "^2.2.20",
    "jsdom": "^25.0.1",
    "lodash": "^4.17.21",
    "luxon": "^3.5.0",
    "math-expression-evaluator": "^1.4.0",
    "mem": "^8.1.1",
    "nanoid": "^3.3.1",
    "pdfmake": "0.2.12",
    "pino": "^9.5.0",
]

I hope this can help to investigate what's happening exactly.

@getsantry getsantry bot moved this to Waiting for: Product Owner in GitHub Issues with 👀 3 Nov 26, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Package: nestjs Issues related to the Sentry Nestjs SDK Waiting for: Product Owner
Projects
Status: Waiting for: Product Owner
Development

No branches or pull requests

4 participants