Replies: 1 comment 2 replies
|
Why hasn’t this post gained more traction? Being able to identify which specific middleware is running seems like a pretty fundamental part of middleware instrumentation, especially when a route has multiple middleware functions. Without a name, index, or function reference, the instrumentation API feels incomplete. This seems like an important feature gap that may have been overlooked. |
2 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
We understand this is an unstable API, so we're raising this more as feedback that we hope is useful in shaping the API as it matures.
What
When using the
unstable_ServerInstrumentationAPI, theroute.instrument({ middleware })callback provides no way to identify which middleware is being instrumented. The callback receiveshandleMiddlewareand{ unstable_pattern }, but no middleware function name, index, or other distinguishing information.This means all middleware spans in a trace end up identical — same name, same attributes — making them impossible to differentiate.
Reproduction
Given a route with multiple middleware:
And instrumentation code:
The resulting trace looks something like:
Every middleware span is indistinguishable. There's no way to tell which function each span corresponds to.
Expected Behavior
It would be really helpful if the
middlewarecallback received the middleware function name (e.g. derived fromfn.name). This is probably what most developers would want to see in a trace.This would enable instrumentation like:
Why This Matters
Middleware is often a significant contributor to request latency in server-rendered React Router apps. The deeply nested span structure means each outer middleware's duration includes all inner middleware + loaders. Without identification, it's hard to pinpoint which middleware is responsible for performance issues — which somewhat defeats the purpose of the instrumentation API.
All reactions