Add platform to Sentry relase

[fluiddot]

Proposed Changes

• Add platform suffix to the Sentry release name. This will allow us to separate the release metrics based on the platform. Ultimately, this would help us to determine the quality of each platform and prioritize bugs accordingly.

Testing Instructions

• Apply the following patch to analyze a Sentry event data.

diff --git forkSrcPrefix/src/index.ts forkDstPrefix/src/index.ts
index 5c14c3c5d29c1b5658b8fd5559283d1f16d845c7..2341225c45476ad36b7bb4587f679b496b61e854 100644
--- forkSrcPrefix/src/index.ts
+++ forkDstPrefix/src/index.ts
@@ -30,8 +30,12 @@ import { stopAllServersOnQuit } from './site-server'; // eslint-disable-line imp
 Sentry.init( {
 	dsn: 'https://97693275b2716fb95048c6d12f4318cf@o248881.ingest.sentry.io/4506612776501248',
 	debug: true,
-	enabled: process.env.NODE_ENV !== 'development',
+	enabled: true,
 	release: `${ app.getVersion() ? app.getVersion() : COMMIT_HASH }-${ getPlatformName() }`,
+	beforeSend: ( event ) => {
+		console.log( 'Sentry event - release:', event.release );
+		return null; //This drops the event and nothing will be sent to Sentry
+	},
 } );
 
 // Handle creating/removing shortcuts on Windows when installing/uninstalling.
@@ -71,6 +75,8 @@ async function appBoot() {
 
 	setupUpdates();
 
+	Sentry.captureMessage( 'test' );
+
 	setupWPServerFiles().catch( Sentry.captureException );
 
 	if ( process.defaultApp ) {

• Build and run the app.
• Check the console logs and observe that the release property of the Sentry event is logged with the following values depending on the platform used:
  • macOS: 1.0.2-macos
  • Windows: 1.0.2-windows
  • Windows: 1.0.2-linux

Pre-merge Checklist

• Have you checked for TypeScript, React or other console errors?

[fluiddot]

For now, this function is only used in the main process (which has access to process object and node). However, I also added support for invocations from the renderer process via the app globals, in case we need it in the future.

[derekblank]

Good idea. 👍

[derekblank]

LGTM. 🚀

I observed that the platform name was appended to the release when logging out the Sentry init values:

macOS: 1.0.2-macos
Windows: 1.0.2-windows

[dcalhoun]

Asking largely for my own education: Is the existing operating system context on all events (e.g., os.name) insufficient for the analysis we desire or do these changes simplify the analysis?

[derekblank]

Asking largely for my own education: Is the existing operating system context on all events (e.g., os.name) insufficient for the analysis we desire or do these changes simplify the analysis?

@dcalhoun One of the reasons prompting this change was filtering the Crash Threshold Alert by platform. When adding another param such as os.name to the Filters list, it appears to return as an invalid search. I have yet to find anything in the docs about why this param might be returning invalid for Crash Free Session Alerts. The param os.name:Windows is autosuggested by the Filter field itself. The only thing I have noted is that when adding a Filter, the request returns 400 Bad Request in the console, suggesting it may be a CORS issue with retrieving the data for the request. We may be missing a config setting to enable this request, either on the Studio client side or in Sentry settings.

Does this match your experience, or do you note a way to filter Crash Alert data by platform (using any available param, not just the ones already mentioned here)?

Updating the Crash Alert Rule with a platform os filter

The 400 Bad Request Response

[fluiddot]

Asking largely for my own education: Is the existing operating system context on all events (e.g., os.name) insufficient for the analysis we desire or do these changes simplify the analysis?

@dcalhoun These changes are needed to split the crash-free metrics by platform. As far as I've checked, I haven't found a way to get those metrics for a specific release or set up an alert (as Derek shared here).

UPDATE: Looks like there's already a feature request on Sentry related to this (getsentry/sentry#58348).

[dcalhoun]

Thanks @derekblank and @fluiddot. You provided the context I was missing — a desire to configure independent health status alerts for each platform. Based on the references you shared, I agree including the platform name in the release name is likely the most straightforward approach for now.