"Duplicate type name" error when fetching similar schemas
See original GitHub issueThere is a bug (at least, I think it’s unexpected behaviour) in the avsc
library where it mutates the passed forSchemaOptions
to add a registry
to it, which then means subsequent calls using the same forSchemaOptions
then crash with a “Duplicate type name” error. See https://github.com/mtth/avsc/issues/312.
This caused a crash for us because the schema registry reuses the options object between calls. So for example, given schemas 1 and 2 which both contain a record with the same name
, the following code will crash:
const reg = new SchemaRegistry(
{ host: 'http://localhost:3322' },
{ forSchemaOptions: {} },
);
await reg.getSchema(1);
await reg.getSchema(2); // Error: duplicate type name
Which is obviously quite a big problem because as soon as we try and parse an old and newer version of a subject, our app crashes with this error.
It’s worth noting that the crash only happens if we specify forSchemaOptions
, as otherwise forSchema
gets called with undefined
and there’s nothing for avsc
to mutate.
So primarily I think this is a bug in avsc
and I wanted you to be aware – in my opinion it should be perfectly valid for the schema registry to pass the same options into it every time. However it might be worth putting a work around in. For our use case we’re patching this line to always pass an empty registry
object in:
this.schemasByRegistryId[registryId] = avro.Type.forSchema(schema, {...this.forSchemaOptions, registry: {}})
so that might be a change worth including for the time being? I’m not sure why avsc
even exposes the registry as an option as it feels like an implementation detail to me, so perhaps there’s some use case I’m not aware of.
Thanks very much!
Issue Analytics
- State:
- Created 3 years ago
- Reactions:6
- Comments:5
I’ve also hit this when attempting to pass
logicalTypes
to the avro options.Had a go at pushing a PR, making this change locally fixed the issue: https://github.com/kafkajs/confluent-schema-registry/pull/209
We are actually experiencing this issue but we don’t use
forSchemaOptions
property. We are setting up ourschemaRegistry
:We populate the
typeMap
variable using this: