Method 'HEAD' already declared for route - regression in 4.24.0

[knolleary]

Prerequisites

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

Fastify version

4.24.0

Plugin version

No response

Node.js version

16.20

Operating system

macOS

Operating system version (i.e. 20.04, 11.3, 10)

latest

Description

With the 4.24.0 release, our application no longer starts due to an error:

Failed to start: Error: Method 'HEAD' already declared for route '/api/v1/devices/:/editor/proxy/*' with constraints '{}'

Our application makes two calls to app.route - the first handles GET requests that could be a WebSocket connection, the second handles all the other methods we need to cope with.

    app.route({
        method: 'GET',
        url: '/proxy/*',
        ...
    })

    app.route({
        method: ['POST', 'DELETE', 'PUT', 'HEAD', 'OPTIONS'],
        url: '/proxy/*',
        ...
    })

With 4.24.0, this second call is triggering the error. Previous versions worked fine.

Steps to Reproduce

I will update with a link to a repo containing as minimal reproduction as I can create tomorrow.

I wanted to get the issue recorded quickly as it appears to be a regression in 4.24.0. Looking at PRs in the release, #5078 appears very relevant.

Expected Behavior

No response

[mcollina]

cc @ivan-tymoshenko

[gurgunday]

I believe it's working correctly now

You need to set exposeHeadRoute: false if you want to create its HEAD separately

[gurgunday]

The following fixes the error:

 app.route({
        method: 'GET',
        url: '/proxy/*',
        exposeHeadRoute: false,
        ...
    })

[mcollina]

If you invert the order of definitions you should be able to unpin it.

[ivan-tymoshenko]

Anyway it looks like a bug. From the code I see, fastify should remove a default HEAD handler and set a custom one. It should not throw. Will take a look tomorrow, if somebody will not solve this earlier.

[ivan-tymoshenko]

There is another small bug in the fastify.

[knolleary]

Thanks all for the fast responses. I can confirm that setting exposeHeadRoute: false has resolved it for us - decided that was a more explicit fix than relying on just the order the routes were registered that could be unknowingly changed in the future.

[mcollina]

decided that was a more explicit fix than relying on just the order the routes were registered that could be unknowingly changed in the future.

It actually is the best choice.

[metcoder95]

Anyway it looks like a bug. From the code I see, fastify should remove a default HEAD handler and set a custom one. It should not throw. Will take a look tomorrow, if somebody will not solve this earlier.

I recall was intended, but not remember why. Anyhow, I agree that fastify should check if the HEAD route already stored was made in auto, and remove it to make the new one take highest priority.

Nvm, see now what’s happening 😓

[ivan-tymoshenko]

I found the problem. Working on it.