Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

kafka + avro: Add a test for subject/schema mismatch #31407

Draft
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

martykulma
Copy link
Contributor

I didn't see any tests that cover subject/schema mismatches. One of the failure scenarios that came out of looking at 8933 is this type of mismatch. Though I'm not sure the best way to incorporate this test.

In order for this test to run reliably, it needs 2 subjects with compatible schemas. We publish a message to a topic, but reference a different schema id in the header. The existing test framework keeps reusing the schema registry, so the schema id is nondeterministic.

options seem to be:

  • reset the schema registry (i.e. drop and recreate kafka + registry) so that we are highly confident of the schema ids
  • add an action to retrieve the id from schema registry (in the same vein as set-from-sql)

for now, it lives in a separate subdirectory so default doesn't try to run it (as it might fail with a different type of error, depending on what schema id 2 ends up being)

 % bin/mzcompose --find testdrive-old-kafka-src-syntax down && bin/mzcompose --find testdrive-old-kafka-src-syntax run default isolated/avro-resolution-schema-subject-mismatch.td

Motivation

coverage for a subject/schema mismatch

Checklist

  • This PR has adequate test coverage / QA involvement has been duly considered. (trigger-ci for additional test/nightly runs)
  • This PR has an associated up-to-date design doc, is a design doc (template), or is sufficiently small to not require a design.
  • If this PR evolves an existing $T ⇔ Proto$T mapping (possibly in a backwards-incompatible way), then it is tagged with a T-proto label.
  • If this PR will require changes to cloud orchestration or tests, there is a companion cloud PR to account for those changes that is tagged with the release-blocker label (example).
  • If this PR includes major user-facing behavior changes, I have pinged the relevant PM to schedule a changelog post.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant