fastify-response-validation icon indicating copy to clipboard operation
fastify-response-validation copied to clipboard

fix: assign schemas to host ajv instance

Open diogosilva95 opened this issue 1 year ago • 6 comments

Fixes the issue #113 by adding the schemas to the internal avj instance used by the plugin

Checklist

diogosilva95 avatar Nov 03 '24 02:11 diogosilva95

@diogosilva95 The CI is failing, can you add a unit test as well please?

Fdawgs avatar Nov 03 '24 10:11 Fdawgs

@Fdawgs added the test and fixed lint :)

diogosilva95 avatar Nov 03 '24 14:11 diogosilva95

Note sure if it is a good idea, when encapsulation is exist, you can have same $id with different content.

would you provide an example please? when you add a schema to the ajv instance with an existing id it throws an error

diogosilva95 avatar Nov 05 '24 08:11 diogosilva95

when you add a schema to the ajv instance with an existing id it throws an error

That is the exact problem I mention, fastify allows the same $id of schema exists across different encapsulated context. You can see the below foo schema shared the same name but different properties.

import fastify from "fastify";

const app = fastify();
app.register(async (instance) => {
  instance.addSchema({
    $id: 'foo',
    type: 'object',
    properties: {
      foo: { type: 'string' }
    }
  })
})
app.register(async (instance) => {
  instance.addSchema({
    $id: 'foo',
    type: 'object',
    properties: {
      foo: { type: 'string' },
      bar: { type: 'string' }
    }
  })
})
await app.ready()

climba03003 avatar Nov 05 '24 17:11 climba03003

Isn't addSchema encapsulation aware?

mcollina avatar Nov 12 '24 13:11 mcollina

The ajv instance is encapsulated too.

The problem is similar to @fastify/swagger. The instance of ajv is global in the root context of registered level. So, the problem still persist, unless it creates a new instance of ajv on each new context creation.

climba03003 avatar Nov 12 '24 18:11 climba03003