Description
Description
Registry
Version: 2.6.2.Final
Persistence type: SQL
Environment
Kubernetes 1.26
Steps to Reproduce
- Create a new artifact in schema registry
- Add two more versions of its schema
- Make sure that all three versions are available in both Apicurio and Confluent-compatible APIs:
http://<schema_registry_url>/apis/registry/v2/groups/default/artifacts/<artifact_name>/versions
http://<schema_registry_url>/apis/ccompat/v7/subjects/<artifact_name>/versions
- Also make sure that a respective subject is availble in the Confluent-compatible API:
http://<schema_registry_url>/apis/ccompat/v7/subjects
- Disable the last version of the artifact:
curl --location --request PUT 'http://<schema_registry_url>/apis/registry/v2/groups/default/artifacts/<artifact_name>/versions/3/state' \
-H "Content-Type: application/json"
--data '{"state": "DISABLED"}'
- Make sure that subject disappeared from Confluent-compatible API, even though there are two enabled versions of it available:
http://<schema_registry_url>/apis/ccompat/v7/subjects
Expected vs Actual Behaviour
Expected behaviour here is that the subject should be available while there is still at least one enabled schema version available.
But for some reason artifact itself transits to disabled state after its last version is being disabled. At the same time it is possible to get all the information regarding its versions from the APIs (both Apicurio and Confluent-compatible).
Confluent-compatible API, for example, returns the latest (second) version of schema in this case with no problem from this endpoint (works fine in UI as well):
http://<schema_registry_url>:8080/apis/ccompat/v7/subjects/<artifact_name>/versions/latest
Metadata
Metadata
Assignees
Labels
Type
Projects
Status