DefaultSchemaResolver resolve schema by content second attempt with canonical=false fails

[wolfchimneyrock]

Description

Registry
Version: 3.0.0.M5
Persistence type: postgresql

#5108 introduced a second attempt at resolving a schema by content with canonical=false if the first attempt with canonical=true fails. however, it doesn't attach the schema as payload to the request, so apicurio responds back with

400
BadRequestException: Empty content is not allowed.

I think the issue is that the second request re-uses the already exhausted ByteArrayInputStream is from the first request, when it should instead have a new ByteArrayInputStream from the original data.

apicurio-registry/schema-resolver/src/main/java/io/apicurio/registry/resolver/DefaultSchemaResolver.java

Lines 273 to 295 in 18061af

	InputStream is = new ByteArrayInputStream(contentKey.getBytes(StandardCharsets.UTF_8));
	String at = schemaParser.artifactType();
	String ct = toContentType(at);
	VersionSearchResults results = client.search().versions().post(is, ct, config -> {
	config.queryParameters.groupId = artifactReference.getGroupId() == null ? "default"
	: artifactReference.getGroupId();
	config.queryParameters.artifactId = artifactReference.getArtifactId();
	config.queryParameters.canonical = true;
	config.queryParameters.artifactType = at;
	config.queryParameters.orderby = VersionSortBy.GlobalId;
	config.queryParameters.order = SortOrder.Desc;
	});
	if (results.getCount() == 0) {
	results = client.search().versions().post(is, ct, config -> {
	config.queryParameters.groupId = artifactReference.getGroupId() == null ? "default"
	: artifactReference.getGroupId();
	config.queryParameters.artifactId = artifactReference.getArtifactId();
	config.queryParameters.canonical = false;
	config.queryParameters.artifactType = at;
	config.queryParameters.orderby = VersionSortBy.GlobalId;
	config.queryParameters.order = SortOrder.Desc;
	});

[apicurio-bot]

Thank you for reporting an issue!

Pinging @jsenko to respond or triage.

[carlesarnal]

Hello @wolfchimneyrock, thanks for raising this. Yes, that's indeed the problem. The subsequent call was added as part of debugging, and I left it there because I think it's actually helpful, but apparently I messed up with the input stream. I have attached a PR that solves the problem.