Support Fastify 4

[mydea]

Prerequisites

• I have written a descriptive issue title
• I have searched existing issues to ensure the feature has not already been requested

🚀 Feature Proposal

We at Sentry ship the fastify instrumentation as a dependency to our users, so that users get fastify instrumentation out of the box.

We would have a hard time updating to this package, as this only instruments fastify 5+, and obviously the vast majority of our users is not on fastify 5, so they would stop getting instrumentation.

Would it be hard to also support fastify 4 here? Looking at this PR: https://github.com/open-telemetry/opentelemetry-js-contrib/pull/2460/files it seems that it should be possible to support both versions. Considering fastify 5 is out for a pretty short time only, so far 🤔

Motivation

We want to be able to provide fastify instrumentation for as many users as possible.

Example

No response

[jsumners]

https://fastify.dev/docs/latest/Reference/LTS/

Notice that v4 is only supported through the end of June 2025. Basically only 5 months at this point. In my opinion, it would be far wiser for people to focus their efforts on migrating to v5 instead of adding support to this module for v4.

[Eomm]

From my POV, since we are in the 0.x version and the v4 support is still there, I would cut a release tested with fastify v4 that should not take a too much effort.

I would not like to abandon our users for a string check at this stage: the open-telemetry org give us that ownership and they were supporting fastify v3 too
fastify/fastify#5862

What I would like to understand is: what are we missing for a v1 @metcoder95 from your prospective?

The perfect scenario I see is the following (but it requires more effort):

• ship a v1 tested with fastify v3 that we will no maintain in future
• ship a v2 tested with fastify v4 that we will no maintain after the EOL (June 2025)
• ship a v3 tested with fastify v5 that we will keep up to date

[metcoder95]

Feature wise, the library should be ok for reaching a stable version, tho I've been waiting until it is merged to the OTel registry to make the official transition.

OTel team is at a disposal of maintain their instrumentation for the upcoming months until v4 gets EOL.

There's no much effort on supporting v4 within the v1 of the instrumentation, tho it is hard to try to ensure compatibility with even older versions (v3 backwards).

The last being said, I'm fine with releasing v1 with support for Fastify v4 and expedite a v2 scoping to support only v5.

OTel support should be enough for covering v3, wdyt?

[mcollina]

Let's finish support for v5, then identify how hard it would be to support Fastify v4, if at all possible.

[Eomm]

Feature wise, the library should be ok for reaching a stable version, tho I've been waiting until it is merged to the OTel registry to make the official transition.

Is there a PR already or should we do it?

Not sure if these are enough:

• docs(instrumentation-fastify): deprecate instrumentation in favor of @fastify/otel open-telemetry/opentelemetry-js-contrib#2651
• feat(auto-instrumentations-node)!: disable @opentelemetry/instrumentation-fastify by default open-telemetry/opentelemetry-js-contrib#2652

[metcoder95]

Yeah, these are enough and handled by the OTel team. On our end is only needed to add it to the registry, PR sitting for review: open-telemetry/opentelemetry.io#6024