Error: Cannot find module '/.next/server/app/(account)/binaries/sentry_cpu_profiler-v93-darwin-arm64.node'

[tholder]

Is there an existing issue for this?

• I have checked for existing issues https://github.com/getsentry/profiling-node/issues
• I have reviewed the documentation https://docs.sentry.io/
• I am using the latest SDK release https://github.com/getsentry/profiling-node/releases

SDK Version

0.3.0

What environment is your node script running in?

Local dev using nvm node v18.15.0

Are you using an alpine based docker image?

• Yes (please specify the version)
• No (please describe your environment)

Does the failure occur on a remote environment only?

• Yes (please describe your environment)
• No (please describe your local environment)

Are you using alpine based node docker image. If so, what version are you using? e.g node:16-alpine3.12

No response

If you are using alpine, have you tried using latest version of alpine or (currently alpine3.16 or alpine3.17)?

• Yes (please specify the version)"
• No, and I cannot upgrade

Have you tried using the latest minor version of node (currently 16.20 or 18.15)?

• Yes (please specify the version)
• No, and I cannot upgrade

If you run npm install --verbose --foreground-scripts @sentry/profiling-node in an empty directory, what is the output?

n.a

Crash report

On Apple M1 receive error:

error - Error: Cannot find module '/.next/server/app/(account)/binaries/sentry_cpu_profiler-v93-darwin-arm64.node

[tholder]

Also tried:

yarn add @sentry/node @sentry/profiling-node

Still same error.

[tholder]

Should add, this is next 13 and the error seems odd that it's looking for binary actually in my /app folder. (account) as shown above is just a next 13 pattern for organizing files that don't impact the url.

[JonasBa]

Hmm, @tholder, it definitely should not look for the binary there. How are you initializing the Sentry SDK?

Mind sharing the full error stack trace btw error - Error: Cannot find module '/.next/server/app/(account)/binaries/sentry_cpu_profiler-v93-darwin-arm64.node can sometimes be caused by a failing dlopen, but it's usually visible in the full stack trace

[tholder]

I just ran through the next setup with the automated setup.

The profiling I setup exactly as shown when you go to the profiling page and click 'Set Up Profiling'.

See:

Full stack trace here:

Error: Cannot find module '/Users/tholder/Documents/boardshape/boardshape/.next/server/app/(account)/binaries/sentry_cpu_profiler-v93-darwin-arm64.node'
  at webpackEmptyContext(app:///Users/tholder/Documents/boardshape/boardshape/.next/server/app/(account)/agendas/page.js:22:10)
  at importCppBindingsModule(webpack-internal:///(sc_server)/./node_modules/@sentry/profiling-node/lib/cpu_profiler.js:22:95)
  at eval(webpack-internal:///(sc_server)/./node_modules/@sentry/profiling-node/lib/cpu_profiler.js:30:25)
  at Object.(sc_server)/./node_modules/@sentry/profiling-node/lib/cpu_profiler.js (file:///Users/tholder/Documents/boardshape/boardshape/.next/server/app/(account)/agendas/page.js:4455:1)
  at __webpack_require__(app:///Users/tholder/Documents/boardshape/boardshape/.next/server/webpack-runtime.js:33:43)
  at eval(webpack-internal:///(sc_server)/./node_modules/@sentry/profiling-node/lib/hubextensions.js:8:24)
  at Object.(sc_server)/./node_modules/@sentry/profiling-node/lib/hubextensions.js (file:///Users/tholder/Documents/boardshape/boardshape/.next/server/app/(account)/agendas/page.js:4477:1)
  at __webpack_require__(app:///Users/tholder/Documents/boardshape/boardshape/.next/server/webpack-runtime.js:33:43)
  at eval(webpack-internal:///(sc_server)/./node_modules/@sentry/profiling-node/lib/integration.js:8:25)
  at Object.(sc_server)/./node_modules/@sentry/profiling-node/lib/integration.js (file:///Users/tholder/Documents/boardshape/boardshape/.next/server/app/(account)/agendas/page.js:4499:1)

[tholder]

Interestingly I see it says 'We've received this project's first profile' but nothing shows up on the page.

We are running next 13.3.0 - there is a newer version as of today I think which is mean to be production ready so I'll upgrade and try again.

[marcoturi]

same here but with serverless

"@sentry/serverless": "7.50.0",
"@sentry/profiling-node": "0.3.0"

Sentry.AWSLambda.init({
  dsn: config.SENTRY_DSN,
  release: pkg.version,
  enabled: !process.env.IS_OFFLINE,
  environment: config.ENV,
  tracesSampleRate: config.IS_PRODUCTION ? 0.2 : 1,
  profilesSampleRate: config.IS_PRODUCTION ? 0.2 : 1,
  integrations: [
    new ProfilingIntegration(),
  ],
});

Error: Cannot find module '/var/task/binaries/sentry_cpu_profiler-v108-linux-x64-glibc.node'\nRequire stack:\n- /var/task/src/handler.js\n- /var/runtime/index.mjs

[JonasBa]

@marcoturi is your action bundled by any chance?

[marcoturi]

yes @JonasBa it is, through https://github.com/floydspace/serverless-esbuild if you need I can share my build configuration

[JonasBa]

Ah yes @marcoturi, I suspect the binary might not correctly be copied over to the correct location. Can you confirm if you are seeing the binary as part of the final bundle?

[JonasBa]

@marcoturi I just had a look at how this is handled in other packages that deal with native bindings (sharp came to mind). It seems they expect you to make the package as external, do you mind testing that and telling me if it works?
You can follow the same steps as here under serverless-esbuild https://sharp.pixelplumbing.com/install#bundlers except instead of marking sharp you would obviously need to mark @sentry/profiling-node as the external package

[marcoturi]

@JonasBa
It works!

  esbuild:
    packager: 'yarn'
    external:
      - '@sentry/profiling-node'
    bundle: true
    minify: true
    sourcemap: true
    keepNames: true
    watch:
      pattern:
      - "src/**/*.(ts|ejs)"

Two downside that I can notice now:

• Size is increased of 3.6 MB (without profiling 6.24 MB - with profiling 9.99 MB). With lambda and cold restarts this could be a problem.
• Info on sentry dashboard are not so useful. I don't see any info on the functions called in the stack trace, I just get the average ms of the whole lambda without distinguish between events (note: I use the lambda for several events/endpoint from appsync)

[tholder]

Good you got it sorted but I think whether profiler is a worthwhile addition for you isn't really relevant to this issue.

I still don't have a solution for the original issue which is with next 13. As Next 13 uses turbopack I'm not yet sure how to apply the same fix.

[JonasBa]

@tholder yeah, sorry we should have moved this into a separate issue, I just wasn't sure if it might be of similar nature - I will need to test how turbopack handles this, likely sometime next week.

@marcoturi glad you got it working. Just to address your points:

Size is increased of 3.6 MB (without profiling 6.24 MB - with profiling 9.99 MB). With lambda and cold restarts this could be a problem.

A large majority of these are unused binaries, it should not significantly impact cold start, but please do let me know if it does. In the future we will bundle all library code so you only end up with a single executable (+ the binaries)

Info on sentry dashboard are not so useful. I don't see any info on the functions called in the stack trace, I just get the average ms of the whole lambda without distinguish between events (note: I use the lambda for several events/endpoint from appsync)

I can see the flamegraph doesn't show much data, might need a few transactions to become more useful as it's aggregated data. If you click on one of the recent profiles in the 2nd table below the flamegraph, is the data there more actionable?

In order to not pollute this issue any further, mind just taking this to email? Feel free to send me an email to [email protected] or [email protected] and we can tackle everything there.

[JonasBa]

@tholder Just to get some extra info, are you using nextjs 13.4 or any of the other minor versions (if so, which one)?
Are you specifying any build flags to enable turbopack or is this the out of the box experience?

[tholder]

The error occurred on 13.3 but I have since upgraded to 13.4. I'll try re-installing with this version next week.

[JonasBa]

@tholder ok, I will investigate this. Will be doing a lot of SDK work next week and will try tackle this as well. We have users on nextjs who use profiling, I'm just not sure what version they are running. I will test the turbopack setup and update with what I find

[fundlg]

I have same issue with solito monorepo (including nextjs app - v13.0.7, node - v16.14.2):
Cannot find module '/Users/user/Projects/project/node_modules/@sentry/profiling-node/binaries/sentry_cpu_profiler-v93-darwin-arm64.node'
I believe that module path is correct, but the folder does not contain required file.
Does anyone have similar issue resolved?
Using macbook pro m1 max.

[JonasBa]

@fundlg since we use dynamic require based on arch and platform, bundlers determine the static set of files they need to move, this means the binary file is never moved and the MODULE_NOT_FOUND error is correctly thrown. I'm going to be investigating this issue today, one possible solution seems to be to just enumerate all possible supported platforms which is probably what I will do, I just need to validate that it actually fixes this bug in the commonly used bundlers.

[fundlg]

Thanks! Will wait for updates

[JonasBa]

Ok, so I reworked the binary loading here so that it can be properly enumerated by bundlers (confirmed with esbuild and webpack) and copied to outdir. PR was merged as esbuild and webpack are both stable bundlers - will look into turbopack now.

[JonasBa]

@fundlg and @tholder my current fix only fixes the situation for platforms that we provide prebuilt binaries for (darwin is currently compiled from source). I'm going to look into adding this in CI as github runners are now in beta, once that is done, they should be automatically picked up and moved to the dest folder. Sorry for the long turnaround, I know this is annoying for you to wait for, but it requires me to move quite a few things around and test.

[JonasBa]

Github actions struggling during these past two days has also been a nice source of frustration 😭

[JonasBa]

@fundlg @tholder, since gh is having issues, do you mind running npm install --verbose --foreground-scripts @sentry/profiling-node and pasting the output? The binaries in dev should be compiled from source for your platforms.

I just created a sample next ^13.4.1" project using node 16.16 on M1 and after adding npm i @sentry/profiling-node and running next dev I can see my API route being correctly profiled.

[fundlg]

@JonasBa hey, I've tried to install package with npm install --verbose --foreground-scripts @sentry/profiling-node and looks like it works for me now. Looks like it requires to have python3 or python installed locally and have an environment variable to the python binary path. After fixing it package was installed successful.

Thanks!

[JonasBa]

@fundlg yes, you python3 is required by node-gyp so that we can compile the binary from source. The env variable with path to the correct binary should not be necessary though, do you still get the same error if you do not set the env variable?

[KrustyC]

I have encountered the same exact issue and tried the following, but the error persists:

• run rm -rf node_modules package-lock.json
• run npm install again

I then tried to run npm install --verbose --foreground-scripts @sentry/profiling-node and this is the output I got:

npm verb cli /Users/ACCOUNT/.nvm/versions/node/v18.14.0/bin/node /Users/ACCOUNT/.nvm/versions/node/v18.14.0/bin/npm
npm info using [email protected]
npm info using [email protected]
npm verb title npm install @sentry/profiling-node
npm verb argv "install" "--loglevel" "verbose" "--foreground-scripts" "@sentry/profiling-node"
npm verb logfile logs-max:10 dir:/Users/ACCOUNT/.npm/_logs/2023-05-18T16_13_55_088Z-
npm verb logfile /Users/ACCOUNT/.npm/_logs/2023-05-18T16_13_55_088Z-debug-0.log
npm http fetch GET 200 https://registry.npmjs.org/@sentry%2fprofiling-node 2662ms (cache revalidated)
npm verb reify failed optional dependency /PATH/TO/REPO/node_modules/@next/swc-win32-x64-msvc
npm verb reify failed optional dependency /PATH/TO/REPO/node_modules/@next/swc-win32-ia32-msvc
npm verb reify failed optional dependency /PATH/TO/REPO/node_modules/@next/swc-win32-arm64-msvc
npm verb reify failed optional dependency /PATH/TO/REPO/node_modules/@next/swc-linux-x64-musl
npm verb reify failed optional dependency /PATH/TO/REPO/node_modules/@next/swc-linux-x64-gnu
npm verb reify failed optional dependency /PATH/TO/REPO/node_modules/@next/swc-linux-arm64-musl
npm verb reify failed optional dependency /PATH/TO/REPO/node_modules/@next/swc-linux-arm64-gnu
npm verb reify failed optional dependency /PATH/TO/REPO/node_modules/@next/swc-darwin-arm64
npm http fetch POST 200 https://registry.npmjs.org/-/npm/v1/security/advisories/bulk 1015ms

up to date, audited 578 packages in 4s

162 packages are looking for funding
  run `npm fund` for details

found 0 vulnerabilities
npm verb exit 0
npm info ok 

I am running on a Macbook Air (2015) with MacOs BigSur installed.

[JonasBa]

@KrustyC, hmm, it seems that postinstall never runs so the binary is never built from source 🤔 It seems similar to what @fundlg was reporting. Do you have python3 installed on your machine? You can run python3 --version to output python version.

[fundlg]

@JonasBa Yes, I have it installed locally. Looks like I had to provide env variable in ~/.zshrc - build from source doesn't work without it

python3 --version
Python 3.10.9

[snovak7]

Receive similar with the latest nextjs 13.4.4 on Windows as-well (standalone mode) (next dev, build)
Cannot find module '....next\server\binaries\sentry_cpu_profiler-v108-win32-x64.node'

[JonasBa]

I'm going to investigate this. My best guess is that postinstall silently fails here and we don't see the binding compile errors

[Llanilek]

Similar trying to install on ubuntu 22.

Error: ENOENT: no such file or directory, rename '/home/ubuntu/backend/node_modules/@sentry/profiling-node/build/Release/sentry_cpu_profiler.node' -> '/home/ubuntu/backend/node_modules/@sentry/profiling-node/lib/sentry_cpu_profiler-linux-arm64-glibc-83.node'
    at Object.renameSync (fs.js:798:3)
    at file:///home/ubuntu/backend/node_modules/@sentry/profiling-node/scripts/copy-target.mjs:18:4
    at ModuleJob.run (internal/modules/esm/module_job.js:183:25)
    at async Loader.import (internal/modules/esm/loader.js:178:24)
    at async Object.loadESM (internal/process/esm_loader.js:68:5)
    at async handleMainPromise (internal/modules/run_main.js:59:12) {
  errno: -2,
  syscall: 'rename',
  code: 'ENOENT',
  path: '/home/ubuntu/backend/node_modules/@sentry/profiling-node/build/Release/sentry_cpu_profiler.node',
  dest: '/home/ubuntu/backend/node_modules/@sentry/profiling-node/lib/sentry_cpu_profiler-linux-arm64-glibc-83.node'
}
@sentry/profiling-node: Failed to build from source, please report this a bug at https://github.com/getsentry/profiling-node/issues/new?assignees=&labels=Type%3A+Bug&template=bug.yml
internal/modules/cjs/loader.js:1173
  return process.dlopen(module, path.toNamespacedPath(filename));

[DiegoRBaquero]

Happening in GH action since upgrading version:

Error: /usr/src/app/node_modules/@sentry/profiling-node/lib/sentry_cpu_profiler-linux-arm64-glibc-108.node: cannot open shared object file: No such file or directory

[JonasBa]

Can someone please test if removing yarn.lock or package-lock.json and running npm install resolves the issue? This seems very similar to the issue described here. Additionally, can someone share what version of npm you are running by doing npm -v or yarn -v so I can try and replicate the problem? Since we run compile via postinstall scripts, it is possible that that config option is disabled, hence binaries are never compiled. We can validate if postintall is ignored if you run npm config get ignore-scripts --global (it should be set to false)

[Llanilek]

@JonasBa

yarn -v
1.22.19

npm config get ignore-scripts --global
false

Can confirm that removing the lock file does fix the issue but only temporarily. As soon as CI tries to re-run it comes up with the error again.

[JonasBa]

@Llanilek would you mind testing 1.0.4 - I changed to run the compile check during install vs postinstall phase.

[Llanilek]

@Llanilek would you mind testing 1.0.4 - I changed to run the compile check during install vs postinstall phase.

@JonasBa I'll give it a whirl shortly. We had to remove profiling temporarily as it was blocking our deployment and we needed to get something out quick. I'll load it back up again later and give it a whirl.

[JonasBa]

Has anyone tested this recently? It should be fixed since the last version and I haven't seen any new reports coming about this issue

[jl75]

I just tested this. Error remains.
Error: Cannot find module './sentry_cpu_profiler-darwin-arm64-108.node'

npm config get ignore-scripts --global
false

next 13.4.7 (latest)
@sentry/nextjs 7.57.0 (latest)
@sentry/profiling-node 1.0.7 (latest)
node v18.16.0
Python 3.11.4
Apple clang version 14.0.0 (clang-1400.0.29.202)
Running on macOS Monterey 12.6.4 (MacBook Pro, M2).

npm install --verbose --foreground-scripts @sentry/profiling-node

Seems okay. Only one error:

install response status 404 Not Found on https://github.com/Automattic/node-canvas/releases/download/v2.11.2/canvas-v2.11.2-node-v108-darwin-unknown-arm64.tar.gz
Pre-built binaries not installable for [email protected] and [email protected] (node-v108 ABI, unknown) (falling back to source compile with node-gyp)

Proceeds to build from source. I then get a lot of linker warnings:

ld: warning: dylib (/opt/homebrew/XXXX/YYYY/VERSION/lib/libZZZZ.dylib) was built for newer macOS version (12.0) than being linked (11.0).

Finally: "Some issues need review, and may require choosing a different dependency."

[jl75]

Somehow, the required build scripts are not run. I have come up with a quick workaround:

npm i @sentry/profiling-node
cd node_modules/@sentry/profiling-node
npm run build:configure:arm64
npm run build:bindings:arm64

The library will now be compiled for the arm64 architecture and copied to the destination. Your project should subsequently be able to find the library and build successfully.

@JonasBa: This workaround could provide directions for correcting the build scripts. For further investigation take a look at: node_modules/@sentry/profiling-node/package.json

There are some potentially related issues that could hopefully be solved together:
#168
#171
maybe even: #104

[timonmasberg]

Has anyone tested this recently? It should be fixed since the last version and I haven't seen any new reports coming about this issue

i have, same issue on 1.0.7.

[whaagmans]

Somehow, the required build scripts are not run. I have come up with a quick workaround:

npm i @sentry/profiling-node cd node_modules/@sentry/profiling-node npm run build:configure:arm64 npm run build:bindings:arm64

The library will now be compiled for the arm64 architecture and copied to the destination. Your project should subsequently be able to find the library and build successfully.

@JonasBa: This workaround could provide directions for correcting the build scripts. For further investigation take a look at: node_modules/@sentry/profiling-node/package.json

There are some potentially related issues that could hopefully be solved together: #168 #171 maybe even: #104

Can confirm that this works. Creating the binary if it is not the list of precompiled binaries, ty @jl75.
Hopefully, this helps find the issue otherwise, it has to be run manually by every developer in the codebase.

[JonasBa]

We've released 1.0.8 and some folks internally at Sentry who had issues with this have said that the release resolved it for them. Do you mind upgrading and letting me know if this still happens?

[JonasBa]

That said, I am currently looking at providing prebuilt binaries for darwin/arm64. I suspect none of you run prod system on these. It's a small win, but I would like to save everyone the headache of installing build tooling and having to recompile from source when you install the package.

[stafflink-hrishi]

I was having a similar issue with dlopen on m1 MAC (Ventura 13.5_, the error I was seeing was "not a mach-o file" for the cpu profiler binary. The problem was the python version (3.11.2), after I switched to 3.10.12 and reinstalled/rebuilt the binary it worked.

[AmirL]

Have the same issue with NextJs 13 and profiler.

"@sentry/node": "^7.63.0",
"@sentry/profiling-node": "^1.1.2",
"lerna": "^6.6.2",

I build it in Docker with "node:18-alpine"

[BABEL] Note: The code generator has deoptimised the styling of /app/node_modules/@sentry/profiling-node/lib/index.js as it exceeds the max of 500KB.

...


Failed to compile.

../../node_modules/@sentry/profiling-node/lib/sentry_cpu_profiler-darwin-arm64-83.node
Module parse failed: Unexpected character '�' (1:0)
You may need an appropriate loader to handle this file type, currently no loaders are configured to process this file. See https://webpack.js.org/concepts#loaders
(Source code omitted for this binary file)
Import trace for requested module:
../../node_modules/@sentry/profiling-node/lib/sentry_cpu_profiler-darwin-arm64-83.node
../../node_modules/@sentry/profiling-node/lib/index.js
./sentry.server.config.ts
./src/app/layout.tsx

[JonasBa]

@AmirL this is a different issue - you need to configure a .node loader for your application.

I will close this issue as binaries should now be prebuild and available. If you are seeing a Module parse failed: Unexpected character '�' (1:0) this means the binary is there, you just need to configure a .node-loader.

Tldr, but for esbuild you will need to add

loader: {
    '.node': 'copy',
  },

and for webpack, you will need https://webpack.js.org/loaders/node-loader/.

@stafflink-hrishi your issue seems different than the original issue described (I will create a new issue)

[AmirL]

@JonasBa Can it be added to the Sentry setup manual for NextJs?

[alvincrisuy]

@AmirL I am encountering the same issue. have you solved the problem?

CC: @JonasBa would it be best to show how I can use the mentioned solution in serverless bundle?

[OliverMax]

Hi guys. I have the same issue.
We are using docker with node:21-alpine image and nuxt.js:3.9.3

As I understand the last version of sentry 1.3.5 incompatible with our node 21 version.
The /node_modules/@sentry/profiling-node/lib directory hasn't 120 file version but 115 and below.

Another strange thing that I can swith to 21 version of node via nvm, build it and run app.
And i still havn't 120 version of file in lib folder

[sheyDev]

Same issue when enabling sentry with NestJS on windows

[JonasBa]

@sheyDev what version of node are using?

@OliverMax It's not that it is incompatible, it's just that we do not build binaries for it. If you install the tooling, you can still compile and run the binaries yourself

[spacestierman]

Not sheyDev, but I am also running into the same problem on Windows:

Windows:

Edition	Windows 11 Pro
Version	23H2
Installed on	‎10/‎10/‎2023
OS build	22631.3447
Experience	Windows Feature Experience Pack 1000.22688.1000.0

Node:

λ node -v
v21.4.0

package.json:

    "@sentry/node": "7.112.1",
    "@sentry/profiling-node": "7.112.1",

Stacktrace:

Error: Cannot find module 'C:\dev\test\node_modules\@sentry\profiling-node\lib\sentry_cpu_profiler-win32-x64-120.node'
Require stack:
C:\dev\test\node_modules\@sentry\profiling-node\lib\index.js
    at Module._resolveFilename (node:internal/modules/cjs/loader:1144:15)
    at a._resolveFilename (C:\dev\test\node_modules\tsx\dist\cjs\index.cjs:1:1760)
    at Module._load (node:internal/modules/cjs/loader:985:27)
    at Module.require (node:internal/modules/cjs/loader:1235:19)
    at require (node:internal/modules/helpers:176:18)
    at importCppBindingsModule (C:\dev\test\node_modules\@sentry\profiling-node\src\cpu_profiler.ts:130:52)
    at Object.<anonymous> (C:\dev\test\node_modules\@sentry\profiling-node\src\cpu_profiler.ts:133:92)
    at Module._compile (node:internal/modules/cjs/loader:1376:14)
    at Object.F (C:\dev\test\node_modules\tsx\dist\cjs\index.cjs:1:1323)
    at Module.load (node:internal/modules/cjs/loader:1207:32) {
  code: 'MODULE_NOT_FOUND',
  requireStack: [
    'C:\\dev\\test\\node_modules\\@sentry\\profiling-node\\lib\\index.js'
  ]
}

Sure enough, when I look in C:\dev\test\node_modules\@sentry\profiling-node\lib\, I do see several .node files, but not the one it is looking for (sentry_cpu_profiler-win32-x64-120.node):

C:\dev\test\node_modules\@sentry\profiling-node\lib
λ ls -al
total 2508
drwxr-xr-x 1 developer 197121      0 Apr 23 08:39 ./
drwxr-xr-x 1 developer 197121      0 Apr 23 08:39 ../
-rw-r--r-- 1 developer 197121 115794 Apr 23 08:39 index.js
-rw-r--r-- 1 developer 197121 267237 Apr 23 08:39 index.js.map
-rw-r--r-- 1 developer 197121 104277 Apr 23 08:39 sentry_cpu_profiler-darwin-arm64-108.node
-rw-r--r-- 1 developer 197121 104277 Apr 23 08:39 sentry_cpu_profiler-darwin-arm64-115.node
-rw-r--r-- 1 developer 197121 103877 Apr 23 08:39 sentry_cpu_profiler-darwin-arm64-93.node
-rw-r--r-- 1 developer 197121 120456 Apr 23 08:39 sentry_cpu_profiler-darwin-x64-108.node
-rw-r--r-- 1 developer 197121 122424 Apr 23 08:39 sentry_cpu_profiler-darwin-x64-115.node
-rw-r--r-- 1 developer 197121 103648 Apr 23 08:39 sentry_cpu_profiler-darwin-x64-93.node
-rw-r--r-- 1 developer 197121  67296 Apr 23 08:39 sentry_cpu_profiler-linux-arm64-glibc-108.node
-rw-r--r-- 1 developer 197121  67296 Apr 23 08:39 sentry_cpu_profiler-linux-arm64-glibc-115.node
-rw-r--r-- 1 developer 197121  67328 Apr 23 08:39 sentry_cpu_profiler-linux-arm64-glibc-93.node
-rw-r--r-- 1 developer 197121  65992 Apr 23 08:39 sentry_cpu_profiler-linux-arm64-musl-108.node
-rw-r--r-- 1 developer 197121  65992 Apr 23 08:39 sentry_cpu_profiler-linux-arm64-musl-115.node
-rw-r--r-- 1 developer 197121  66032 Apr 23 08:39 sentry_cpu_profiler-linux-arm64-musl-93.node
-rw-r--r-- 1 developer 197121  74600 Apr 23 08:39 sentry_cpu_profiler-linux-x64-glibc-108.node
-rw-r--r-- 1 developer 197121  74600 Apr 23 08:39 sentry_cpu_profiler-linux-x64-glibc-115.node
-rw-r--r-- 1 developer 197121  74640 Apr 23 08:39 sentry_cpu_profiler-linux-x64-glibc-93.node
-rw-r--r-- 1 developer 197121  72472 Apr 23 08:39 sentry_cpu_profiler-linux-x64-musl-108.node
-rw-r--r-- 1 developer 197121  72472 Apr 23 08:39 sentry_cpu_profiler-linux-x64-musl-115.node
-rw-r--r-- 1 developer 197121  72896 Apr 23 08:39 sentry_cpu_profiler-linux-x64-musl-93.node
-rwxr-xr-x 1 developer 197121 204288 Apr 23 08:39 sentry_cpu_profiler-win32-x64-108.node*
-rwxr-xr-x 1 developer 197121 204288 Apr 23 08:39 sentry_cpu_profiler-win32-x64-115.node*
-rwxr-xr-x 1 developer 197121 204288 Apr 23 08:39 sentry_cpu_profiler-win32-x64-93.node*
drwxr-xr-x 1 developer 197121      0 Apr 23 08:39 types/
drwxr-xr-x 1 developer 197121      0 Apr 23 08:39 types-ts3.8/```

[sheyDev]

@sheyDev what version of node are using?

@OliverMax It's not that it is incompatible, it's just that we do not build binaries for it. If you install the tooling, you can still compile and run the binaries yourself

@JonasBa I'm using v21.7.2

[JonasBa]

@sheyDev, we do not support non LTS (odd) node versions, so you will either have to downgrade to v20, build the binaries yourself (cd to installed package directory and run build:bindings:configure and build:bindings) or wait for the upgrade to v22.

I think there shouldnt be an issue in building from source. If you see, let us know and we can take a look

[andrewdavidcostello]

For anyone using AWS CDK, had to add nodeModules: ['@sentry/profiling-node'], to the bundling options of the NodejsFunction.