We see an issue where producers of data are using version 1 of a schema when the registry has up to version 2 (backwards compatible). When the spring cloud client gets the available schemas for the subject, it picks the latest version but it doesn't change the actual schema object.
ResponseEntity<List> response = this.template.getForEntity(this.endpoint + "/subjects/" + subject + "/versions",
List.class);
final List body = response.getBody();
if (!CollectionUtils.isEmpty(body)) {
version = (Integer) body.get(body.size() - 1);
}
This seems like incorrect behavior. It makes sense to use the latest version because of compatibility assertions but when you do, you need to use the actual schema for that id. For comparison, we can see confluent's serializer
} else if (useLatestVersion) {
restClientErrorMsg = "Error retrieving latest version of Avro schema";
schema = (AvroSchema) lookupLatestVersion(subject, schema);
id = schemaRegistry.getId(subject, schema);
}
here they get both latest id and version while writing. But in the spring cloud code, we are only using the List.class response to get the size of the list (number of schemas).
We see an issue where producers of data are using version 1 of a schema when the registry has up to version 2 (backwards compatible). When the spring cloud client gets the available schemas for the subject, it picks the latest version but it doesn't change the actual schema object.
https://github.com/spring-cloud/spring-cloud-schema-registry/commit/740c811d6ced20f2d6668282d17c25ea7f71f256
This seems like incorrect behavior. It makes sense to use the latest version because of compatibility assertions but when you do, you need to use the actual schema for that id. For comparison, we can see confluent's serializer
here they get both latest id and version while writing. But in the spring cloud code, we are only using the
List.classresponse to get the size of the list (number of schemas).