feat(astro): Register astro route provider - #23792
Conversation
size-limit report 📦
|
|
This pull request has gone three weeks without activity. In another week, I will close it. But! If you comment or otherwise update it, I will reset the clock, and if you apply the label |
e2e9043 to
8d918ed
Compare
e2504e2 to
b3d3aa2
Compare
47c9fed to
5cca66c
Compare
|
bugbot run |
There was a problem hiding this comment.
Cursor Bugbot has reviewed your changes and found 1 potential issue.
❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.
Reviewed by Cursor Bugbot for commit 5cca66c. Configure here.
5cca66c to
bccce36
Compare
bccce36 to
516cd19
Compare
|
👋 @chargome, @nicohrubec — Please review this PR when you get a chance! |
516cd19 to
a0aae23
Compare
a0aae23 to
c0e0f62
Compare
c0e0f62 to
1c20b40
Compare
b519333 to
d85a851
Compare
The middleware already injects the parameterized route into the document it renders, but it was only readable from the pageload instrumentation. Registered from `init()` rather than the tracing integration, so route parameterization no longer depends on tracing being enabled. Not a matcher: the document only describes the page it rendered, so a URL other than the current one resolves to undefined rather than a guess. Verified against Astro 5.18 that `ClientRouter` swaps the tag during `astro:after-swap", at the same moment `location` changes, so reading it per call stays correct across soft navigations and back/forward.
d85a851 to
2582827
Compare

Registers a route provider for Astro from the
sentry-route-namemeta tag the middleware already injects into every rendered document.Registered from
init()rather than the tracing integration, so route parameterization no longer depends on tracing being enabled.Unlike the Next.js and Remix providers this is not a matcher. The document only ever describes the page it rendered, so a URL other than the current one resolves to
undefinedrather than a guess. That guard is also what stops a navigation being named after the route it is leaving.I checked the soft-navigation behaviour against Astro 5.18 with a throwaway app rather than assuming it.
ClientRouterswaps the tag duringastro:after-swap, at the same momentlocationchanges, and does not accumulate duplicates, so reading it per call stays correct across client-side navigations and back/forward. It is only stale during a navigation, before the swap, which the current-path guard already excludes.Part of #23556