@sentry/astro hard-codes DSN during build stage for output:server with node

arty-name commented 1 month ago

Is there an existing issue for this?

[X] I have checked for existing issues https://github.com/getsentry/sentry-javascript/issues
[X] I have reviewed the documentation https://docs.sentry.io/
[X] I am using the latest SDK release https://github.com/getsentry/sentry-javascript/releases

How do you use Sentry?

Self-hosted/on-premise

Which SDK are you using?

@sentry/astro

SDK Version

8.8.0

Framework Version

4.10.0

Link to Sentry event

No response

SDK Setup

  output: 'server',
  adapter: node({ mode: 'standalone' }),
  integrations: [sentry({ enabled: true })],

Steps to Reproduce

Run astro build without providing DSN
Run PUBLIC_SENTRY_DSN=FAIL astro preview

Or visit the minimal reproduction at https://stackblitz.com/edit/github-5bh1gz?file=package.json

Expected Result

Sentry should log Invalid Sentry Dsn: FAIL

Actual Result

Sentry ignores the provided DSN and does not activate.

Sentry logs this error if you provide PUBLIC_SENTRY_DSN=FAIL during the build stage. Providing a correct DSN at runtime does not fix that.

Lms24 commented 1 month ago

Hey @arty-name thanks for writing in!

If I understand correctly, the issue seems to be that when we generate the server-side Sentry.init code, we use import.meta.env.PUBLIC_SENTRY_DSN, which, during build already, is replaced by the environment variable's value. So you're not able to override the value during runtime with PUBLIC_SENTRY_DSN. Is this correct?

If so, I think we could get away with replacing import.meta.env with process.env but not sure yet

arty-name commented 1 month ago

You understood the issue correctly, Lukas!

I do believe that the change to process.env should help. By the way, in case you haven’t stumbled on this yet, Astro node integration handles the environment variables in a peculiar manner.

Lms24 commented 1 month ago

That's peculiar indeed and I wasn't aware of this at all 😬 I guess we need to try if switching to process.env would make any difference at all then. But ultimately, I believe this is only something users can control.

getsentry / sentry-javascript