You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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_ServerInstrumentation API, the route.instrument({ middleware }) callback provides no way to identify which middleware is being instrumented. The callback receives handleMiddleware and { 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.
exportconstplatformInstrumentation: unstable_ServerInstrumentation={route(route){route.instrument({asyncmiddleware(handleMiddleware,{ unstable_pattern }){// No way to know which middleware this istracer.startActiveSpan('middleware',{attributes: {'rr.route.id': route.id,'rr.route.pattern': unstable_pattern,}},async(span)=>{awaithandleMiddleware();span.end();});},});},};
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 middleware callback received the middleware function name (e.g. derived from fn.name). This is probably what most developers would want to see in a trace.
This would enable instrumentation like:
asyncmiddleware(handleMiddleware,{ unstable_pattern, name }){tracer.startActiveSpan(`middleware ${name}`,{ ... },async(span)=>{awaithandleMiddleware();span.end();});}
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.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
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.
Beta Was this translation helpful? Give feedback.
All reactions