Apicurio registry compatibility with order of register() operations

The current procedure for registering a schema starts by trying to fetch and update the compatibility rules. This works fine with the Confluent registry, but caused an issue in my testing with Apicurio registry.

Understandably this could be considered an issue with the Apicurio API compatibility layer, but generally the order of operations is unusual. If the existing config is not found, a PUT is still attempted to modify a non-existing config.

A simple workaround was to switch the order of operations from:

1. await this.api.Subject.config(args)
2. await this.api.Subject.updateConfig(args)
3. await this.api.Subject.register(args)

To this (2 & 3 switched):

1. await this.api.Subject.config(args)
2. await this.api.Subject.register(args)
3. await this.api.Subject.updateConfig(args)

AFAICT this works as intended with both registry APIs. Does it make sense to make this change, or would it have unintended side effects?

[Nevon]

Most likely during the week starting May 2nd.

[Nevon]

I suppose in Confluent schema registry when doing updateConfig we’re not dependent on the subject existing because we’re not modifying the subject, we’re modifying the config, which is why we’re able to do that before the subject actually exists. In apicurio I suppose they require the subject to exist before being able to modify the configuration for a subject.

Either way, I think it seems like a reasonable change to make.