Custom Unsupported Media Type Error

[matthyk]

🚀 Feature Proposal

Currently, if no matching content type parser is available, a predefined Unsupported Media Type error is thrown. There should be the possibility that the user can define this error object himself.

Motivation

This would have 2 advantages:

1. If users have a default format for errors that looks different from Fastify's current one, then they could use that format on the Unsupported Media Type.
2. Users could define different errors in different plugins.

Example

This could be implemented like the addContentTypeParser API.

fastify.setUnsupportedMediaTypeError({
    "statusCode": 415,
    "error": "My Unsupported Media Type",
    "message": "This media type is currently not supported."
})

or like this, which would give the user even more possibilities:

fastify.setUnsupportedMediaTypeError((req, contentType, done) => {
    const myError = {
        requestedContentType: contentType,
        "statusCode": 415,
        "error": "My Unsupported Media Type",
        requestId: req.id
    }
    done(null, myError)
})

[matthyk]

Are you open for a PR?

[RafaelGSS]

Nowadays, you can't check it in the errorHandler?

[matthyk]

Yes it is possible to check in the errorHandler but I think that is not that clean. And you do not have the possibility to define different error shapes in different plugins.

[mcollina]

Instead of focusing on making this customizable, we should focus on allowing the error handler to call the one of the plugin above it. In this way we could even have route-specific error handlers.

[matthyk]

After looking into the code again, I realized that I made a mistake. it is NOT possible to catch the error in the errorHandler. The content type parser runs reply.send(new FST_ERR_CTP_INVALID_MEDIA_TYPE(contentType)) directly. As I understand it, @mcollina proposal could not solve the problem then either.

[mcollina]

reply.send(new FST_ERR_CTP_INVALID_MEDIA_TYPE(contentType)) will call the error handler.

[alainrk]

Instead of focusing on making this customizable, we should focus on allowing the error handler to call the one of the plugin above it. In this way we could even have route-specific error handlers.

@mcollina Doesn't it work like that right now already?
I'm new to using fastify, but isn't it enough to just don't call the setErrorHandler() to have the error propagated to the closest above plugin calling the setErrorHandler().

I tried to write a test for it, that passes, but maybe I'm missing something.

test('custom root and custom plugin error handling with nested plugin throwing', t => {
    t.plan(3)

    const fastify = Fastify()

    fastify.register((instance, options, done) => {

      instance.setErrorHandler((err, req, reply) => {
        throw new Error('/a error')
      })

      instance.register((subinstance, options, done) => {
        subinstance.get('/c', function (req, reply) {
          throw new Error('/a/b/c error')
        })
        done()
      }, { prefix: '/b' })

      done()
    }, { prefix: '/a' })

    fastify.setErrorHandler((err, req, reply) => {
      throw new Error('/ error')
    })

    fastify.inject({
      url: '/a/b/c',
      method: 'GET'
    }, (err, res) => {
      t.error(err)
      t.equal(res.statusCode, 500)
      const payload = JSON.parse(res.payload)
      t.same(payload.message,'/a error')
    })
  })

[Eomm]

Done in #3261

It will be released in fastify v4