Skip to content

feat: Add tracing to load, server actions, and handle/resolve #13900

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Draft
wants to merge 2 commits into
base: elliott/init-tracing
Choose a base branch
from

Conversation

elliott-with-the-longest-name-on-github
Copy link
Contributor

@elliott-with-the-longest-name-on-github elliott-with-the-longest-name-on-github commented Jun 17, 2025

Adds spans to load (on the server), server actions, and handle/resolve.

We're punting on clientside tracing for now, as we do not feel the o11y community has sufficiently converged on approaches (see https://github.com/open-telemetry/community/blob/main/projects/browser-phase-1.md). When OTEL provides a stable and truly browser-native tracing platform, we'll be all over it.

Want to play around with it?

Clone the repo: https://github.com/elliott-with-the-longest-name-on-github/test-tracing

Set up something like Jaeger (you can copy and run the Docker command at the top of this file to get it up and running with UI and ingestion ports): https://www.jaegertracing.io/docs/2.7/getting-started/

Then build and run your app:

pnpm build && node --import ./instrumentation.server.mjs build/index.js

Visit localhost:3000/one/two/three/four, click some buttons to see different scenarios. This will generate traces you can view in Jaeger.

TODO:

  • Configuration to enable globally enabling or disabling telemetry
  • Tests
  • Ask for comments from community -- esp. around what data we're capturing in our attributes and how it's structured, whether we need any additional API surface for annotating spans
  • Test on serverless platforms

Please don't delete this checklist! Before submitting the PR, please make sure you do the following:

  • It's really useful if your PR references an issue where it is discussed ahead of time. In many cases, features are absent for a reason. For large changes, please create an RFC: https://github.com/sveltejs/rfcs
  • This message body should clearly illustrate what problems it solves.
  • Ideally, include a test that fails without this PR but passes with it.

Tests

  • Run the tests with pnpm test and lint the project with pnpm lint and pnpm check

Changesets

  • If your PR makes a change that should be noted in one or more packages' changelogs, generate a changeset by running pnpm changeset and following the prompts. Changesets that add features should be minor and those that fix bugs should be patch. Please prefix changeset messages with feat:, fix:, or chore:.

Edits

  • Please ensure that 'Allow edits from maintainers' is checked. PRs without this option may be closed.

Copy link

changeset-bot bot commented Jun 17, 2025

⚠️ No Changeset found

Latest commit: 3516dd4

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

Copy link
Contributor Author

elliott-with-the-longest-name-on-github commented Jun 17, 2025

Warning

This pull request is not mergeable via GitHub because a downstack PR is open. Once all requirements are satisfied, merge this PR as a stack on Graphite.
Learn more

This stack of pull requests is managed by Graphite. Learn more about stacking.

* @param {any} data
* @param {string} [location_description]
*/
export function validate_load_response(data, location_description) {

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

moved to shared to reduce duplication

* - `'server'` - Enable tracing only on the server side
* - `'client'` - Enable tracing only on the client side
* @default false
* @since 2.22.0

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

TODO

@elliott-with-the-longest-name-on-github elliott-with-the-longest-name-on-github force-pushed the elliott/trace-fns branch 2 times, most recently from 4995112 to 7a3909c Compare June 20, 2025 22:56
Copy link
Contributor

@Lms24 Lms24 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This looks really great, thanks for adding the spans. In fact, you're including more information in the attributes than what I currently add in our build-time load function instrumentation in the Sentry SDK 😅 Really looking forward to removing this in favour of just picking up the new spans!

I Had some suggestions for attribute names and additional spans for sequential handle hooks.

While probably out of scope for this PR: Given the future of load functions, we should probably think about how we can collect spans for async svelte components and remote functions. Though of course this is something for later. Happy to help out!

* @default undefined
* @since 2.22.0
*/
tracing?: 'server';
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I like it! Is the idea here that something like 'client' or 'serverAndClient' could become additional options when client-side tracing is tackled?

Also, I'm realizing this is far-fetched but do you see a world where we (= tracing SDK like Sentry or OTel) could enable this automatically for users? Just asking because for us, ideally, the fewer files users have to touch when setting up Sentry, the better. Also happy to chat about this as a follow-up item as this is already fine for the beginning.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, ideally this becomes 'server' | 'client' | 'both' in the future -- hopefully the OTEL folks can stabilize browser tracing enough that we can do it. (AsyncContext pls???)

Let me discuss with the team on the enabling-for-users thing. It's possible we could provide an enableOtel export or something that could be used in instrumentation.ts to turn it on for users. Will think about it!

},
fn: async () => {
return await with_event(event, () =>
options.hooks.handle({
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

idea: If users use the sequence helper for their handle hooks, we could start spans for each handler in the sequence. This is very helpful to group child spans (e.g. db spans) to a specific handler or generally make it more apparent which of their handlers takes up the most time, etc.

Can of course be done in a follow-up :)

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Huh, not a bad idea... let me see how weird implementing it would be

name: 'sveltekit.handle',
tracer,
attributes: {
'sveltekit.route.id': event.route.id || 'unknown',
Copy link
Contributor

@Lms24 Lms24 Jul 9, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This applies to all spans where the sveltekit.route.id attribute is added. There's a standardized semantic attribute called http.route which should be set to the parameterized route. So I'd recommend switching to this:

Suggested change
'sveltekit.route.id': event.route.id || 'unknown',
'http.route': event.route.id || 'unknown',

(You could also keep of course both attributes but we've seen some user confusion in similar cases with "duplicated" attributes in vercel's ai package)

btw, thanks a lot for including the route name -- this is super helpful for us!

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah see, this is why I "hired" you! 😆 I wasn't sure which attributes might have standardized counterparts I could use. Thanks!

Copy link
Contributor

@Lms24 Lms24 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Another round:

I think for additional spans, it would be great to also capture spans for +server routes (i.e. the GET/POST etc functions). Technically, the handle spans will already tell us by the route id that a +server route was accessed but I'd see a span for the specfic GET/POST/etc handler as quite valuable, similarly to how OTel express instrumentation would record spans for individual request handlers.

Also left a comment about a node_type attribute.

name: 'sveltekit.load',
tracer,
attributes: {
'sveltekit.load.node_id': node.server_id || 'unknown',
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The node_id already gives us insights into if this load function was in a +layout, +page (or +error) node but it contains the whole path (which is good for this attribute, don't get me wrong 😆). We could go one step further and also add something like a sveltekit.node_type attribute.

So basically sveltekit.node_type: '+page' | '+page.server' | '+layout' | ...

No strong opinion though. The main real benefit here would be that you can query, group and aggregate on spans by a specific type easily.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants