Feature Proposal: Shall we replace some API calls from `std::time` with `web_time` to make `TraceLayer` (and more services) WASM compatible?

[Saplyn]

• I have looked for existing issues (including closed) about this

Feature Request

Motivation

I'm developing a qqbot webhook callback handler targeting WASM (to be ran on Supabase Edge Functions' Runtime), and would like to use tower_http::trace::TraceLayer to enable tracing for my application. However, as some time related APIs from standard library (like std::time::Instant::now()) panics on wasm-unkown-unkown, TraceLayer and some other service couldn't be used in WASM context.

By replacing those time related API calls with WASM compatible ones, we can make this crate more accessible to those who wish to use them in WASM context (for example, worker with axum for Cloudflare Workers and edge computing).

Proposal

We could replace std::time with web-time, and gate this behind a cargo feature (for compatibility and those who don't want wasm stuff). I've tried vibe coding with Copilot and it seems to be working, so this should be a viable solution.

Possible drawback is the user will have to download an extra dependency if they enable full.

If possible, I'm willing to do the implementation myself (I would do it by hand and won't vibe code for the PR of course).

Alternatives

An alternative would be not use tower_http::trace::TraceLayer and instead manually implement the tracing stuff. The drawback is the user would have to write a lot more code to get it working.

I chose the proposed solution because it's relatively simple to implement (web-time should be a drop-in replacement for those APIs) and could make more tower-http services available for WASM (edge computing scenario).

[seanmonstar]

This is just my opinion: I'm not a fan of depending on a 3rd-party crate for std::time stuff. I much rather want to use libstd types, and see libstd support wasm better.

[Saplyn]

This is just my opinion: I'm not a fan of depending on a 3rd-party crate for std::time stuff. I much rather want to use libstd types, and see libstd support wasm better.

Fair point, but we can gate this behind a feature like web_time or wasm, so that normal use of it won't be a problem.

Or maybe we can have something like IntoTimeInstant so that user can supply their own time if the std::time don't work for them

[jlizen]

I agree with Sean that taking a dep on web-time isn't ideal. Beyond the philosophical preference for std types, web-time activates on all wasm32-unknown-unknown builds, but not all of those have a JS host (plugin systems, custom embedders, etc.), so it would panic in those environments too.

An injectable clock is the way I'd go here. The trace layer only needs "give me the current instant," so the surface is small:

trait Clock: Send + Sync + 'static {
    fn now(&self) -> Instant;
}

Store it type-erased internally (Option<Arc<dyn Clock>> or similar), expose a .clock(impl Clock) builder method on TraceLayer. No new generic parameters on Trace or TraceLayer, so no semver hazard and no type noise for users who don't need it.

Prior art: hyper does exactly this with hyper::rt::Timer, injected via builder, erased internally, never visible in the service type signature. The cost is one vtable dispatch per request, which is negligible next to the tracing span machinery. We could avoid it entirely if the stored clock is None.

Side benefit: this also enables deterministic testing with fake clocks.

Glad to review such a PR @Saplyn .

[Saplyn]

@jlizen, thanks! I shall start working on this asap. Hopefully finishing it within a week. Just give me some time as end-of-semester is coming

[Saplyn]

@jlizen Is it ok to modify the type signature of TraceLayer<...>? Since all things are statically dispatched via type args (I assume this by reading part of the code), it makes sense to add a new type arg like Clock and defaults to Clock = DefaultClock, like this:

 #[derive(Debug, Copy, Clone)]
 pub struct TraceLayer<
     M,
     MakeSpan = DefaultMakeSpan,
     OnRequest = DefaultOnRequest,
     OnResponse = DefaultOnResponse,
     OnBodyChunk = DefaultOnBodyChunk,
     OnEos = DefaultOnEos,
     OnFailure = DefaultOnFailure,
+    ClockType: Clock = DefaultClock,
 > {
     pub(crate) make_classifier: M,
     pub(crate) make_span: MakeSpan,
     pub(crate) on_request: OnRequest,
     pub(crate) on_response: OnResponse,
     pub(crate) on_body_chunk: OnBodyChunk,
     pub(crate) on_eos: OnEos,
     pub(crate) on_failure: OnFailure,
+    pub(crate) clock: ClockType,
 }

Haven't checked if this would compile tho, the code is just here for demonstration purposes.

---

update: looks like rustc isn't happy with T: Trait at there...

 #[derive(Debug, Copy, Clone)]
 pub struct TraceLayer<
     M,
     MakeSpan = DefaultMakeSpan,
     OnRequest = DefaultOnRequest,
     OnResponse = DefaultOnResponse,
     OnBodyChunk = DefaultOnBodyChunk,
     OnEos = DefaultOnEos,
     OnFailure = DefaultOnFailure,
-    ClockType: Clock = DefaultClock,
+    ClockType = DefaultClock,
 > {
     pub(crate) make_classifier: M,
     pub(crate) make_span: MakeSpan,
     pub(crate) on_request: OnRequest,
     pub(crate) on_response: OnResponse,
     pub(crate) on_body_chunk: OnBodyChunk,
     pub(crate) on_eos: OnEos,
     pub(crate) on_failure: OnFailure,
+    pub(crate) clock: ClockType,
 }

[jlizen]

I would prefer to use type erasure rather than add a generic bound that mostly will not be useful to people, even if it has a default / inference keeps working. I'd rather just have the vtable with dyn instead. We can always add the generic later if it becomes an issue.

[jlizen]

Were you still interested in pursuing this @Saplyn ? Happy to review

[Saplyn]

@jlizen Yes, I'm actually working on it right now. You may track my progress in my repo

(sorry for the delayer contribution, I was busy with my graduation)

[Saplyn]

A sketch PR would be made several minutes later, I'm currently stuck on the design details of Clock trait as I don't want to make adding this feature be a breaking API change.

Specifically, I'm unsure if Clock::{now(), elapsed()} should take &self or &mut self. &self would make the API non-breaking and keep the Copy trait of Layer and Service, but would limit the way custom clock should be implemented. While &mut self would make custom clock a lot easier but lose Copy and may introduce some undesired behaviour.

The current implementation is taking &self

---

Also, it seems that using dyn would also make them non-Copy, so I eventually went with static dispatch with Clock and DurationExt trait abstraction.

---

Oh one more thing, should I make the PR right now? Or should I make the PR after I finish writing the tests?

[jlizen]

I don't mind a draft PR if you want to get initial feedback about design approach. It's a bit difficult for me to follow your queries without context.

[Saplyn]

Got it, a draft one coming right now.

[Saplyn]

#710