Compatibility not set when using the CCOMPAT API

[MandMaric]

Description

Configuring the schema compatibility via ccompat/v6 API seems not to be working.

Registry
Version: 2.4.14. Final
Persistence type: kafkasql

Environment

openshift_container_platform v4.11
Kubernetes v1.24.12+ceaf338

Steps to Reproduce

1. set compatability using the ccompat REST API {APICURIO_REGISTRY_URL}/apis/ccompat/v6/config/{schema_name} -> set to compatibility NONE
2. check the compatibility via ccompat REST API using curl-> it will show the set compatibility (in my case NONE)
3. check the compatbility via the apicurio UI and the compatibility is still unchanged

I had to use the {APICURIO_REGISTRY_URL}/apis/registry/v2 API to set the compatibility and it works fine.
However, ccompat seems to have some issues.

Expected vs Actual Behaviour

Expected: Compatibility is set in the UI when configuring it through the ccompat API
Actual Behaivour: ccompat API behaves as if the compatbility is set but it is not

[apicurio-bot]

Thank you for reporting an issue!

Pinging @jsenko to respond or triage.

[MandMaric]

I forgot to mention. The issue only appears from time to time. For some schemas the compatibility gets updated, but for others it remains unchanged even though the ccompat API shows the changed value

[carlesarnal]

Hmm, this is interesting. I have fixed a few issues on the main branch with the ccompat API. Let's see if I have figured this right, is it working as expected in the API and just having problems in the UI or is it having problems in the API as well? It's not fully clear to me from your message.

[MandMaric]

Hi @carlesarnal no it's not only in the UI. Only the ccompat API behaves as if everything was set correctly, but the compatibility has not changed in the registry.

[EricWittmann]

The issue here is a mismatch between the ccompat API and the core API. The difference is that the core API has a concept of deleting the rule configuration (reverting it to default) for a rule. But the ccompat api does not. The interesting part is the interaction between Global and Schema rules. Here's how it works for the core API:

• If the Compatibility global rule is configured (e.g. is set to FULL) and the Schema Compat rule is NOT SET, then the global rule is applied
• If the Compatibility global rule is configured (e.g. is set to FULL) and the Schema Compat rule is configured, then the local rule is applied

As a result, if you want to set the global Compat rule to FULL, but you want to disable Compat checking for a specific Schema, then you need to set that Schema's Compat rule to NONE. This will then cause the compatibility rule to be skipped for that Schema, even though the Global rule is set to FULL. If you want to remove the local Schema rule override, you can then DELETE the Compat rule config for the Schema. If you do that, then the global rule config (e.g. FULL in this example) will once again apply.

In the ccompat API, there is no concept of deleting the configuration. So the implementation currently treats "set Schema config to NONE" as "delete compat rule config". The consequence of this is that there is NO WAY, using the ccompat API, to handle the scenario described above (global compat set to FULL but fully disabled at the Schema level).

We could, of course, change this so that setting a Schema compatibility to NONE actually sets the rule to that value. If we do this, then there will be no way (using the ccompat API) to "clear" the local Schema override.

Thoughts?