feat(astro): Add Astro 5 support #14613
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Lms24
commented
Dec 6, 2024
Comment on lines
-8
to
+14
| "withastro", | ||
| "astro-component", | ||
| "astro-integration", | ||
| "sentry", | ||
| "apm" | ||
| ], | ||
| "keywords": ["withastro", "astro-component", "astro-integration", "sentry", "apm"], | ||
| "author": "Sentry", | ||
| "license": "MIT", | ||
| "engines": { | ||
| "node": ">=18.14.1" | ||
| }, | ||
| "type": "module", | ||
| "files": [ | ||
| "/build" | ||
| ], | ||
| "files": ["/build"], |
There was a problem hiding this comment.
these are just auto-format changes
❌ 1 Tests Failed:
View the top 1 failed tests by shortest run time
To view more test analytics, go to the Test Analytics Dashboard |
chargome
approved these changes
Dec 6, 2024
size-limit report 📦
|
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR adds support for Astro 5 and an E2E test app for Astro 5 with the new server islands feature.
I tested server islands and found out that we emit a new
http.servertransaction for the island-specific additional http requests. Which is generally good IMO, given that server island requests are routed to the automatically generated/_server-island/[name]Astro endpoint.Why are island requests not trace-connected?
The unfortunate part is that the request made from the browser to the island endpoint on the server is not connected to the same trace as the previous pageload. The reason for this is that the island request is optimized by Astro to be made as early as possible:
IIUC
as="fetch"correctly, this preloads the request and no new request is made for the actualfetch()call. Ourpageloadtransaction even includes aresource.linkspan for the request. However, given thefetch()request isn't really made, we can't attach headers or record anhttp.clientspan for it.IMHO there is also a "good" part to this: Usually, Astro server islands are supposed to be used on statically rendered pages. So the traceId that is currently injected into the
<meta>tags stays constant across all page loads. Meaning if the server endpoint requests were also connected to this trace, it would further blow up the transactions in the trace.Long term, we ideally don't add a
<meta>tag to statically generated pages but let the pageload transaction on the client be head of trace. Then, connecting the server island requests to this pageload would be ideal, if we ever find a way to make this work.