`tracingPlugin` doesn't wrap route handlers registered via `~findRoute`

[logaretm]

When a framework (e.g. nitro) uses a custom ~findRoute function instead of registering routes via h3["~routes"] or h3.on(), the tracingPlugin never wraps those route handlers with wrapEventHandler.

The plugin currently wraps routes in three places:

1. Iterating h3["~routes"] at registration time (line 30)
2. Patching h3.on() for future routes (line 37)
3. Patching h3.use() for middleware (line 49)

But nitro sets h3["~findRoute"] directly (bypassing ~routes entirely) to resolve file-based routes at request time. Since the plugin never intercepts ~findRoute, those route handlers are never wrapped, so no h3.request tracing channel event with type: "route" is ever emitted.

Middleware tracing works fine because nitro pushes global middleware to h3["~middleware"], which the plugin does wrap.

Expected behavior:
A request to a nitro file-based route should emit both a middleware span (type: "middleware") and a route handler span (type: "route").

Actual behavior:
Only middleware spans are emitted. The route handler executes untraced by h3.

[logaretm]

I think this should be fixed on H3 side actually.

[pi0]

Sorry for late response. I kinda feel cost of wrapping on runtime is high. We could do this with nitro vfs handler to wrap handlers directly perhaps?

[logaretm]

I was thinking that, we could but that kind of puts it in Nitro's package so a different channel would be in order. Unless we export a helper to do the needed work from h3 and Nitro uses it in the vfs handler.

What do u think?

EDIT: NVM that would still be runtime, we can do it via codegen on nitro's side but it would need to "pretend" it's h3 or we could just make a Nitro channel in this case.

[pi0]

In the end it is just an h3 handler i think it is fine we use same (h3) channel. only pre-wrap compiled router handlers instead of patching findRoute wrapper.