[nextjs] Fix transaction name getting lost when hitting `_error` page

[lobsterkatie]

In the nextjs SDK, when a user hits the _error page, the original transaction name gets overwritten with _error. This causes two problems:

1. It makes it so a user would not be able to tell that they have a particularly buggy route, since every time it errored, it would show up in the Sentry UI filed under _error rather than the real route name.

2. The DSC can get propagated with the original transaction name, but that then doesn't match up with the eventual transaction name.

We should prevent the original name from getting overwritten.

(This is current as of 7.13.0.)

[lforst]

We should rephrase this issue so that it's clear that this only affects frontend pageload transactions (which get named _error in the case an error occurs in the backend). The backend transaction is still named and parameterized fine.

I believe we even had this behavior before we made any recent Next.js SDK changes.

[lforst]

The DSC can get propagated with the original transaction name, but that then doesn't match up with the eventual transaction name.

That is correct behaviour. The frontend must pick up the transaction name from the backend and put it into DSC no matter what. If there is no backend transaction (and inherently no backend DSC) the SDK currently propagates _error which behavior-wise is probably even fine because all the requests that we wanna trace are kicked off by the _error page and not by the page that is in window.location.pathname.

I actually think the todo I left is wrong. It doesn't matter that DSC and transaction name are different. This only matters in the head SDK which is the Next.js data fetcher instrumentation in our case and that works fine:

sentry-javascript/packages/nextjs/src/performance/client.ts

Lines 79 to 83 in 12c19d0

	// `nextData.page` always contains the parameterized route - except for when an error occurs in a data fetching
	// function, then it is "/_error", but that isn't a problem since users know which route threw by looking at the
	// parent transaction
	// TODO: Actually this is a problem (even though it is not that big), because the DSC and the transaction payload will contain
	// a different transaction name. Maybe we can fix this. Idea: Also send transaction name via pageProps when available.

What we should discuss is if we even want the pageload transaction to be named after the requested route.

But I should definitely change that todo again.