DGS-20986 - Modify POST /subjects lookup to fail only if both normalize=true fails

[Nitss10]

What

This PR modifies the POST /subjects lookup to handle cases where a client might register a schema with normalize=true while the lookup request is made with normalize=false.

Previously, if a lookup failed with normalize=false, the API would immediately return an error. This commit changes that logic. It will now only fail the lookup if it fails with both normalize=false and normalize=true. This ensures that clients, like kSQL, can successfully find schemas that were registered using a different normalization setting.

The new logic is:

1. If a lookup fails with normalize=false, the API will automatically try the lookup again with normalize=true.
2. If the lookup fails with normalize=true, the API will then return an error, as this confirms the schema is genuinely not found under either normalization setting.

Checklist

Please answer the questions with Y, N or N/A if not applicable.

• [y] Contains customer facing changes? Including API/behavior changes
• [n] Is this change gated behind config(s)?
  • List the config(s) needed to be set to enable this change
• [y] Did you add sufficient unit test and/or integration test coverage for this PR?
  • If not, please explain why it is not required
• [ ] Does this change require modifying existing system tests or adding new system tests?
  • If so, include tracking information for the system test changes
• [ ] Must this be released together with other change(s), either in this repo or another one?
  • If so, please include the link(s) to the changes that must be released together

References

JIRA:
https://confluentinc.atlassian.net/browse/DGS-20986

Test & Review

I've tested the new lookup logic with two scenarios:

1. Semantically Equivalent Schema: I registered a schema, then changed the field ordering and performed a lookup with normalize=false. As expected, this initial lookup failed. The system then automatically retried with normalize=true and successfully found the schema.

2. Semantically Different Schema: I attempted a lookup with normalize=true using a semantically different schema. This correctly failed, as the system should not find a match.

This behavior is also fully expressed and validated in the unit test cases.

Open questions / Follow-ups

[confluent-cla-assistant]

🎉 All Contributor License Agreements have been signed. Ready to merge.
_{Please push an empty commit if you would like to re-run the checks to verify CLA status for all contributors.}

[karthikeyanas]

Let's add a test case where semantically same schema with normalize=true fails lookup as we are expected not to retry in this case.

[Nitss10]

But how will semantically same schema with normalize=true fail the lookup? Isnt that what normalization means?

[karthikeyanas]

Ah, that's right. I was looking for the test cases

1. Semantically same schema but with added spaces/ordering succeeds with normalize=false
2. Semantically same schema but with added spaces/ordering succeeds with normalize=true
3. Semantically different schema fails with normalize=false
4. Semantically different schema fails with normalize=true

I think 2 & 4 are already covered by existing cases, we are good with this.

[DhirajSuri27]

Semantically same schema but with added spaces/ordering succeeds with normalize=false

Nit: Shouldn't this fail if the ordering is different and normalize=false ?

[karthikeyanas]

Get approval from @rayokota as well

[sonarqube-confluent]

Analysis Details

1 Issue

• 0 Bugs
• 0 Vulnerabilities
• 1 Code Smell

Coverage and Duplications

• 100.00% Coverage (74.10% Estimated after merge)
• No duplication information (2.00% Estimated after merge)

Project ID: schema-registry

View in SonarQube

[rayokota]

Thanks @Nitss10 , LGTM