tl/dr: Since fastify v4, fastify.register must be awaited when registering the onRoute hook, which is necessary when using wrapRoutes: true
We have a fastify-based web service which uses opentelemetry for tracing (custom traces, db, etc.). To instrument fastify, we use fastify-opentelemetry, which so far worked perfectly.
Since upgrading to fastify v4, we have noticed that the resulting spans from a single request are not connected anymore. Usually, with { wrapRoutes: true }, we would see a trace like this: fastify (GET route/) => manually created span => some DB call. Now, the fastify spans are transmitted on their own, as are the other spans (though in the example above there would still be the connected trace manually created span => some DB call); the spans created inside a route handler do not have the correct parent id set.
It turns out, this it due to a breaking change in fastify. It's necessary to await the fastify.register call which registers fastify-opentelemetry as a plugin.
Maybe the IIFE is not the best approach here, but to me it looks like the simplest at the moment. Let me know if there is a better way 😃 Also, it appears to be the case that everything except the wrapRoutes-Feature works great, even without awaiting the register call.
tl/dr: Since fastify v4,
fastify.register
must be awaited when registering theonRoute
hook, which is necessary when usingwrapRoutes: true
We have a fastify-based web service which uses opentelemetry for tracing (custom traces, db, etc.). To instrument fastify, we use
fastify-opentelemetry
, which so far worked perfectly.Since upgrading to fastify v4, we have noticed that the resulting spans from a single request are not connected anymore. Usually, with
{ wrapRoutes: true }
, we would see a trace like this:fastify (GET route/) => manually created span => some DB call
. Now, the fastify spans are transmitted on their own, as are the other spans (though in the example above there would still be the connected tracemanually created span => some DB call
); the spans created inside a route handler do not have the correct parent id set.It turns out, this it due to a breaking change in fastify. It's necessary to
await
thefastify.register
call which registersfastify-opentelemetry
as a plugin.Maybe the IIFE is not the best approach here, but to me it looks like the simplest at the moment. Let me know if there is a better way 😃 Also, it appears to be the case that everything except the wrapRoutes-Feature works great, even without awaiting the register call.