Add Sentry

[apedroferreira]

Closes #998

Adds Sentry to Toolpad - reporting errors in client and server.

Most of this configuration should be correct, but I cannot get any errors to create issues in the MUI Sentry account...
Not sure what might be wrong, I've tried with a personal account and error reporting seems to work, so the problem seems to be related with the MUI Sentry account in specific. (Nevermind, I found and fixed the problem)

• API route errors create issues correctly
• Frontend errors create issues correctly (without being stopped by error boundaries, for example)
• Datasource/query errors create issues correctly?

[render]

Your Render PR Server URL is https://toolpad-pr-1043.onrender.com.

Follow its progress at https://dashboard.render.com/web/srv-ccl1ge02i3mqcbhrm740.

[bharatkashyap]

Looks good! Is there a way to test out whether we're receiving the logs?
Also, do we want to see logs in deploy previews?

[apedroferreira]

Looks good! Is there a way to test out whether we're receiving the logs?

Should be working in the preview now, I've set up the environment variables.
Our credentials for Sentry are in https://www.notion.so/mui-org/Sentry-5784d0f006b9464b847953c3b23e5311.

Also, do we want to see logs in deploy previews?

I think the plan for now is to enable Sentry in demo only.
I've enabled it for this specific preview though with the IS_SENTRY_ENABLED environment variable.

[Janpot]

I've enabled it for this specific preview though with the IS_SENTRY_ENABLED environment variable

not defining the TOOLPAD_SENTRY_DSN variable means disabling sentry. no need to add more redundant variables. also, I'd keep the convention of prefixing Toolpad variables with TOOLPAD_

[Janpot]

sure this is build time only? i.e. we bake it in the image? self hosters can't add their own sentry?

[apedroferreira]

not defining the TOOLPAD_SENTRY_DSN variable means disabling sentry. no need to add more redundant variables. also, I'd keep the convention of prefixing Toolpad variables with TOOLPAD_

Makes sense, I was thinking of this env variable as more like an on/off toggle but you're right, it's redundant, better to just use TOOLPAD_SENTRY_DSN.

[apedroferreira]

sure this is build time only? i.e. we bake it in the image? self hosters can't add their own sentry?

Ok then we shouldn't have this as a built time variable here (I was planning to ask you how the build-time variables work in specific too as I wasn't sure about them).
How can I make an environment variable readable to the Next.js client-side though, without prefixing it with NEXT_PUBLIC? I need to do that for the Sentry DSN variable. (edit: I've used a runtime env variable for it now - please let me know if it's correct!)

[Janpot]

I'm not sure NEXT_PUBLIC_ variables make sense for us

Suggested change

	const SENTRY_DSN = process.env.SENTRY_DSN || process.env.NEXT_PUBLIC_SENTRY_DSN;
	const SENTRY_DSN = process.env.SENTRY_DSN;

[apedroferreira]

What's the right way to have a client-side readable environment variable in our project, if it's not a build-time variable? Is it using the runtime config, like I've changed it to now?

[Janpot]

@apedroferreira Hmm, I'm not sure this would work well for us. This only gets executed at build time. Would it still work if we don't upload sourcemaps and instead rely on production sourcemap urls? https://nextjs.org/docs/advanced-features/source-maps#configuration-flag

[apedroferreira]

Which thing in specific would not work well?
I added this dryRun condition because if dryRun has its default value Sentry seems to require an auth token, but an auth token should not be required if someone is not using Sentry.
This logic seems to fix that issue both locally and in production.

[apedroferreira]

i could add a comment making it more clear though if that's the confusion

edit: it could also be that i set the auth token in production though and the issue is still there, i can try to check again

[apedroferreira]

if it's about hideSourceMaps and there's a chance they could still be visible in the browser, we can try not uploading them and setting them manually in Sentry just for safety

[Janpot]

I don't mind them being visible in the browser. This is an OS project after all 🙂 .
My point is basically, if we have sourcemaps publicly available, hosted from the toolpad application, do we still need to upload them for Sentry? Will Sentry find the sourcemaps if our js files have //# sourceMappingURL directives? If yes, then I'd just disable uploading them altogether.

If Sentry can't work like that, then I think we should make this a separate env variable specifically for the build process that explicitly enables uploading sourcemaps (e.g. TOOLPAD_UPLOAD_SOURCEMAPS or something, not user facing)

[bytasv]

Seems that we should be fine having soruce-maps hosted with app itself: https://docs.sentry.io/platforms/javascript/sourcemaps/#2-provide-source-maps-to-sentry

[oliviertassinari]

I wish Sentry would more clearly explain why they recommend uploading. Their callout https://docs.sentry.io/platforms/javascript/sourcemaps/uploading/hosting-publicly/ doesn't make sense to me: