FastifyDeprecation warning for accessing `request.routerPath` when accessing a non-existing page

[omBratteng]

Separating the issue reported here #1275 (comment)

What version of OpenTelemetry are you using?

@opentelemetry/instrumentation-fastify@032.3

What version of Node are you using?

v18

What did you do?

Instrumented node with fastify instrumentation, did a request to a non-existing page.

Can be reproduced by starting the fastify example and doing a request to any non-existent page

curl http://localhost:8080/i_do_not_exist

What did you expect to see?

No deprecation notices

What did you see instead?

(node:9) [FSTDEP017] FastifyDeprecation: You are accessing the deprecated "request.routerPath" property. Use "request.routeOptions.url" instead. Property "req.routerPath" will be removed in `fastify@5`.

Additional context

We are using the latest version of the intrumentation

https://github.com/dailydotdev/daily-api/blob/dc3bbecd7c04984a60a224b19ae9752102caf09e/package.json#L48

and version 4.24.2 of fastify

https://github.com/dailydotdev/daily-api/blob/dc3bbecd7c04984a60a224b19ae9752102caf09e/package.json#L71

So digging a bit further into it, I think it might when the requests are to not found pages. but then both request.routeOptions.url and request.routerPath are undefined.

[Wazbat]

I'm also getting this when accessing existing pages, is that perhaps an unrelated issue?

See #1757 (comment)

[omBratteng]

That might be related to #1275 which should have been fixed in #1679

[dyladan]

I'll cut a release that includes #1679 and we can see if this is fixed. Seems to me that it shoudl be.

[10xLaCroixDrinker]

@dyladan That says it was released 3 weeks ago. Was it not?

[dyladan]

Sorry I didn't confirm before typing that. @Wazbat can you confirm your issue is fixed?

Seems we didn't catch all uses of deprecated properties then

[trentm]

@dyladan I can take this. I was just looking at it.

[omBratteng]

I think the issue is that on 404 pages, neither request.routeOptions.url or the deprecated request.routerPath is available. Could maybe check if request.is404 is false and then set the path?

[Wazbat]

Sorry I didn't confirm before typing that. @Wazbat can you confirm your issue is fixed?

I'm using the following packages and versions:

{
    "@autotelic/fastify-opentelemetry": "^0.17.1",
    "@opentelemetry/instrumentation": "^0.44.0",
    "@opentelemetry/instrumentation-fastify": "^0.32.3",
    "@opentelemetry/instrumentation-http": "^0.44.0",
    "@opentelemetry/resources": "^1.17.1",
    "@opentelemetry/sdk-trace-node": "^1.17.0",
    "fastify": "^4.24.3",
}

And simplified app is as follows

import Fastify from 'fastify';
import openTelemertryPlugin from '@autotelic/fastify-opentelemetry';
const fastify = Fastify();
await fastify.register(openTelemertryPlugin, {
    wrapRoutes: ['/my/route']
});
fastify.post('/my/route', async (req, res) =>{
    const { activeSpan } = req.openTelemetry();
    activeSpan?.setAttributes({ key: 'value' });
    res.send('whatever');
});

When running my application with this, I'm seeing these logs

(node:1) [FSTDEP017] FastifyDeprecation: You are accessing the deprecated "request.routerPath" property. Use "request.routeOptions.url" instead. Property "req.routerPath" will be removed in `fastify@5`.

[omBratteng]

@Wazbat it's the @autotelic/fastify-opentelemetry plugin that is using the routerPath
https://github.com/autotelic/fastify-opentelemetry/blob/41dfdb788acbb83733052cf0cfe5060e8ad677ae/index.js#L14-L15

[trentm]

Could maybe check if request.is404 is false and then set the path?

I'd prefer not to have different logic to try to sniff if the new attributes are the appropriate ones to use. I saw some reference about undefined values for a Fastify error as well. My suspicion is that cases other than a 404 might have an empty request.routeOptions.url.

request.routeOptions was added in fastify/fastify#4397 and it included .url from its inception. So I'm planning to switch on if the request.routeOptions property exists.

---

Currently I'm adding a 404 test case and there is a separate weirdness. The fastify.name property is added to the span, but it is assuming all handlers are user-provided handlers, and not built-in ones:

      const handlerName = handler?.name.substr(6);

There it is assuming a handler is of the form bound whateverUserHandlerFunctionName. However, for a 404 the handler.name is basic404: https://github.com/fastify/fastify/blob/396b8b95bf0f1313b9deeb387d68fdc7ffa97abe/lib/fourOhFour.js#L48