Adjust span names to say "(partial render tree)" instead of "RSC" for RSC requests

[lforst]

What?

This PR removes the RSC prefix from OpenTelemetry span names for "RSC Requests". From my understanding RSC Requests in the code base are requests that are made as part of a navigation in app router, requesting an RSC payload.

Why?

This should probably be changed because a) it does not follow the Semantic OpenTelemetry conventions (https://opentelemetry.io/docs/specs/semconv/http/http-spans/#name) b) it causes grouping issues with other RSC requests that are non navigational, like prefetch requests, and initial pageloads/hard-navigations.

The original PR that added this prefix does not contain a description so I may lack some background info as to why the prefix was introduced in the first place: #62464

In my opinion, it is not clear to downstream users what the "RSC" prefix actually means, so it is fine to remove. I am happy to learn something different though!

How?

Right now this PR simply updates the name. In theory, no data is lost because the fact whether the request was an "RSC request" by the definition above is still stored as a next.rsc span attribute.

Relates to #64723
Fixes getsentry/sentry-javascript#13597

[ijjk]

Allow CI Workflow Run

• approve CI run for commit: aa91899

Note: this should only be enabled once the PR is ready to go and can only be enabled by a maintainer

[dvoytenko]

@lforst This change makes sense for HTTP layer. However, RSC requests are different from standalone (root?) requests: they may only execute a partial render tree. This would often lead to RSC requests being much faster/cheaper that standalone requests, which might cause confusion. E.g. if one sets up a performance monitor on the duration of a "GET /my/route/[slug]" span, but RSC vs standalone timings will be wildly different. WDYT?

[lforst]

@dvoytenko I see your concern 🤔 I assumed that RSC requests are also always full requests.
I can see the risk of conflating two different types of request handlers, however, I think I would still go through with the rename and transfer the information one or more layers down in the abstraction tree. Simply because it is more conventional that way.

At the level where we are creating the GET /... span, we are still very much at the HTTP layer. If we created child spans for the HTTP spans that are named differently for RSC requests and “root” requests that would totally work in my opinion.

[lforst]

The more I think of this the more sense it makes to keep the spans for RSC and "root" requests separate names. Maybe the wording of "RSC" is just very confusing because I would have expected that "root" requests are also React Server Component requests.

Would there be appetite to rename the spans into something like GET /my/route (partial render tree)?

[dvoytenko]

Would there be appetite to rename the spans into something like GET /my/route (parial render tree)?

IMHO stressing "partial" in the name makes a lot of sense to me.