Frontend performance insights breaking behavior after a 9.40-> 9.45 upgrade

[angelikatyborska]

Is there an existing issue for this?

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

How do you use Sentry?

Sentry Saas (sentry.io)

Which SDK are you using?

@sentry/astro

SDK Version

9.46.0

Framework Version

Astro 5.13.3

Link to Sentry event

No response

Reproduction Example/SDK Setup

// sentry.server.config.ts

import * as Sentry from "@sentry/astro";
import { nodeProfilingIntegration } from "@sentry/profiling-node";

if (import.meta.env.PUBLIC_IS_SENTRY_ENABLED === "1") {
 Sentry.init({
 dsn: import.meta.env.PUBLIC_SENTRY_DSN,
 environment: import.meta.env.PUBLIC_APP_ENV,
 ignoreTransactions: ["https://api.storyblok.com"],

 integrations: [
 // Add our Profiling integration
 nodeProfilingIntegration(),
 ],

 // Set sampling rate for profiling
 // This is relative to tracesSampleRate
 profilesSampleRate: 1.0,
 // Define how likely traces are sampled. Adjust this value in production,
 // or use tracesSampler for greater control.
 tracesSampleRate: 0.15,
 });

 Sentry.setTag("execution_context", "server");
}

// sentry.client.config.ts

import * as Sentry from "@sentry/astro";

import websiteConfig from "./src/config/websiteConfig";

if (import.meta.env.PUBLIC_IS_SENTRY_ENABLED === "1") {
 Sentry.init({
 dsn: import.meta.env.PUBLIC_SENTRY_DSN,
 environment: import.meta.env.PUBLIC_APP_ENV,
 ignoreErrors: [
 // caused by top-level await, unsupported by Chrome <88, triggered most often by job scrapers
 "Unexpected reserved word",
 "await is a reserved identifier",
 ],
 integrations: [
 Sentry.extraErrorDataIntegration(),
 // note that this plugin doesn't work as expected for errors sent from the dev server
 // because the dev server doesn't apply the necessary 'application key' to frames
 Sentry.thirdPartyErrorFilterIntegration({
 behaviour: "apply-tag-if-exclusively-contains-third-party-frames",
 filterKeys: [websiteConfig.SENTRY.APPLICATION_KEY],
 }),
 ],

 // Define how likely traces are sampled. Adjust this value in production,
 // or use tracesSampler for greater control.
 tracesSampleRate: 0.15,
 });

 Sentry.setTag("execution_context", "client");
}

Steps to Reproduce

Roughly 2 weeks ago, we have updated the @sentry/astro package in our project from v9.40.0 to v.9.45.0. We didn't do any other changes - it was a simple dependabot PR.

Expected Result

We expected this upgrade not to have any visible changes for us. We read the changelog and the only change in versions from 9.41 to 9.45 that was marked as "important" was:

Important Changes
feat(v9/core): Deprecate experimental enableLogs and beforeSendLog option (#17092)

Which didn't apply to our project, so we expected there to be no breaking changes.

Actual Result

What actually happened, which we only noticed today, is that our frontend performance metrics changed completely. Instead of being reported by exact page path (e.g. /page-a, /page-b) and so on, they're all now all reported under a single catch-all page /[...slug]. This makes them unusable for us.

Here's an explanation why that's bad for us:

We're using a headless CMS to create content for our Astro website. We have a single Astro page file /[...slug].astro which reads the page slug and fetches dynamic content from the CMS. We (the development team) have no control over which page contains what content. It could be any of our 100+ components that are available in our CMS to be inserted in any page. We also have no control over which page slugs exist - a big team of content editors creates and deletes those as they please.

On /page-a, the editors might have inserted ComponentA, ComponentB, and ComponentC. On page /page-b, they might have inserted ComponentX. ComponentX might be causing a bad layout shift. This will only affect /page-b and not /page-a. If all of our core web vitals are reported together under a single /[...slug] path, then we have no chance of finding out which exact page is having performance issues.

[linear]

JS-893 Frontend performance insights breaking behavior after a 9.40-> 9.45 upgrade

[Lms24]

Hey, thanks for reporting! What you're experiencing is #17143, introduced with 9.41.0 (or rather #17133, which is the original PR).

This was an intentional change because generally, Sentry wants to show you the parameterized version of the route a user is on. Say you have a very dynamic page like /users/details/123 and /users/details/456, you most likely want to know the aggregated performance insights for the actual /users/details/:userId route, and not separated insights for thousands of users.

Now, in your case, where you don't want parameterized routes, you can update the span name, using the beforeStartSpan callback in browserTracingIntegration. You can probably just use location.pathname as shown in the code example.

Let me know if this solves your problem!