You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The server tells the browser which trace it belongs to through a <meta name="sentry-trace"> tag. The problem is that the cached shell can contain a tag from an old render, while the fresh part contains a tag for the current request. Today we avoid the problem by not emitting any tags at all, so pageloads and server requests are never connected.
Changes:
re-enable tags in cacheComponents
A tag inside <body>, or one that shows up after the SDK started, was rendered for this visitor. Use it as the parent of the pageload. This is the normal connected trace.
A tag inside <head> that is already there when the SDK starts could come from a cached shell. Do not continue it. Instead, add a span link of type cache_origin that points at it. The pageload keeps its own trace and makes its own sampling decision.
If several tags exist, prefer the last one in the document. The fresh one always comes later.
Because the fresh part can arrive after the SDK started, watch the document for a new tag until the page has finished loading.
Remove the old generateStaticParams based meta tag stripping (removeIsrSsgTraceMetaTags and the isrRoutes manifest field). The head-tag rule covers it.
Tests:
E2E tests in both cacheComponents apps for these page types:
A page whose shell was generated on the first visit (a generateStaticParams route visited with an id that is not in the list): the second visitor's pageload must not share a trace with the first visitor's.
A page that renders fully on every request (export const instant = false): the tag is in the head, so the pageload links to it but keeps its own trace.
A fully static page: no tag, fresh trace.
Remove the old test that asserts the pageload is never connected.
Run the ISR e2e apps to confirm cached pages still start their own trace.
The server tells the browser which trace it belongs to through a
<meta name="sentry-trace">tag. The problem is that the cached shell can contain a tag from an old render, while the fresh part contains a tag for the current request. Today we avoid the problem by not emitting any tags at all, so pageloads and server requests are never connected.Changes:
<body>, or one that shows up after the SDK started, was rendered for this visitor. Use it as the parent of the pageload. This is the normal connected trace.<head>that is already there when the SDK starts could come from a cached shell. Do not continue it. Instead, add a span link of typecache_originthat points at it. The pageload keeps its own trace and makes its own sampling decision.generateStaticParamsbased meta tag stripping (removeIsrSsgTraceMetaTagsand theisrRoutesmanifest field). The head-tag rule covers it.Tests:
E2E tests in both cacheComponents apps for these page types:
generateStaticParamsroute visited with an id that is not in the list): the second visitor's pageload must not share a trace with the first visitor's.export const instant = false): the tag is in the head, so the pageload links to it but keeps its own trace.