feat(leptos-axum): propagate trace context to server functions

[janu-cambrelen]

What

This PR modifies the handle_server_fns_inner function within the Axum integration to enable trace context propagation to server functions.

Why

Parent contexts — whether passed from the client or created via middleware — were not associated with downstream spans. This led to disjointed and incomplete traces. With this change, downstream spans will now be properly associated with their upstream context:

#[server]
#[cfg_attr(feature = "ssr", tracing::instrument)]
pub async fn some_server_fn() -> Result<(), ServerFnError> {
    use server_imports::*;
    
    // The generated `__some_server_fn` span will now be a child of the propagated parent span.
    // Furthermore, any child events or spans herein will also share the common trace ID.

    Ok(())
}

How

By introducing two changes:

1. Capturing Current Span: Before spawning the task that contains/runs server functions, the current span is captured via let current_span = tracing::Span::current().
2. Entering Span Scope: Inside the task, a guard is created using current_span.enter(). This ensures that the current span is set as the active span for the duration of the task.

[benwis]

I'd love to have better tracing support. Does it work well on regular pages?

[janu-cambrelen]

I'd love to have better tracing support. Does it work well on regular pages?

Sure thing, @benwis! It can work with requests from a Leptos frontend or any other client as long as the necessary trace context headers are present in the request. Otherwise, a new span can be created via middleware and serve as the parent span to any tracing activities within server functions. Prior to this change, the trace context was lost at the server function; now, instrumented requests from server functions can be traced across a distributed system / service boundaries with continuity.

As far as better tracing support, perhaps a feature flagged/gated OpenTelemetry implementation can be useful. However, it can become rather complex pretty quickly. An example of how to implement it for those using SSR can be useful, though. I will give it some thought.

I appreciate the quick review and thank you for your contributions.

[benwis]

It's great to see someone else with interest, I spent some time fiddling with tracing with Honeycomb a while baack, and I could never quite get the internal leptos tracing on route request to be included in the same span as the initial trace from the tower middleware. So I'm hoping you have better luck than me

[janu-cambrelen]

Worked like a charm for me! This change may have been the missing piece for you. May be worth another attempt if you're interested. If you do decide to go down that rabbit hole again, feel free to ping me. I'd be happy to assist.

[pythoneer]

@janu-cambrelen do you know if that would work with sentry(-tracing .. etc)? If yes, how would that look like, i guess you would #[tracing::instrument] the server functions, like in your example but i don't really get what the leptos/client side would look like to "start" a span in the browser and sync the trace ID.