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

Merged
merged 11 commits into from
Jul 23, 2025

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

image

Adds spans to load (on the server), server actions, and handle/resolve. It also adds a tracing object with rootSpan and currentSpan to the RequestEvent, ServerLoadEvent, and LoadEvent types. This means you can get access to a span to annotate it pretty much anywhere -- including using getRequestEvent (this could be quite nice for library integrations!).

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 page 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 ./instrument.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: 923af08

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.

* - `'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 3 times, most recently from 7a3909c to 3516dd4 Compare June 20, 2025 23:03
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!

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.

Copy link
Member

@benmccann benmccann left a comment

Choose a reason for hiding this comment

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

Could we put this behind an experimental flag like we've been doing with the other larger features recently? It seems like it'd be a nice way to gather feedback about the spans that we're providing

It'd also probably be helpful to add a docs page for this

@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 12e313d to 124687d Compare July 16, 2025 21:43
@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 9ecd13d to 17898be Compare July 16, 2025 22:59
/**
* Whether to enable serverside OpenTelemetry tracing for SvelteKit operations including handle hooks, load functions, and form actions.
* @default undefined
* @since 2.22.0 // TODO: update this before publishing

Choose a reason for hiding this comment

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

TODO, need to update this directly prior to merging

@@ -49,6 +50,13 @@ export const handleError = ({ event, error: e, status, message }) => {
};

export const handle = sequence(
({ event, resolve }) => {

Choose a reason for hiding this comment

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

Some things we want to test, like navigation, actually involve two requests, so the traces will have two separate trace IDs. This allows us to set a stable ID across all of the traces for a given test so that we can pull them out of the file we write to the disk. We put them on the root span (rather than the span associated with this specific handle function) so that we can easily find the root span, then rebuild the span tree from there.

import fs from 'node:fs';

/** @implements {SpanExporter} */
class FilesystemSpanExporter {

Choose a reason for hiding this comment

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

I am reasonably sure this can replace our error serialization stuff, because the OTEL integration captures error spans. Will do it in a followup PR sometime in the future, or never, depending on how motivated I am and how much more-important work there is to do 😆

return JSON.stringify(span_data);
});

fs.appendFileSync(this.#path, serialized_spans.join('\n') + '\n');

Choose a reason for hiding this comment

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

using jsonl conventions so that we can just spam the lines into the file without having to parse/reserialize it all the time

read_traces: async ({}, use) => {
/** @param {string} test_id */
function read_traces(test_id) {
const raw = fs.readFileSync('test/spans.jsonl', 'utf8').split('\n').filter(Boolean);

Choose a reason for hiding this comment

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

I could see this becoming inefficient / slowing down tests if we start using it more widely -- it may need optimization in the future

if (root_traces.length === 0) {
return [];
}
return root_traces.map((root_trace) => {

Choose a reason for hiding this comment

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

this should significantly increase the efficiency of building the tree as the number of spans associated with a given trace is quite small compared to the total number of spans

@eltigerchino eltigerchino added the feature / enhancement New feature or request label Jul 23, 2025
@eltigerchino eltigerchino merged commit 78a65ea into elliott/init-tracing Jul 23, 2025
18 of 19 checks passed
@eltigerchino eltigerchino deleted the elliott/trace-fns branch July 23, 2025 08:03
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature / enhancement New feature or request
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants