Conversation
Contributor
|
The latest Buf updates on your PR. Results from workflow Buf CI / validate (pull_request).
|
Contributor
✅ Clean — no registry drift, off-token colours, or ad-hoc classesApp:
Generated by lookout audit-changes. |
r-vasquez
changed the title
r-vasquez
force-pushed
the
rv/sr-context-aware-schema-resolution
branch
from
September 16, 2026 03:35
59defa7 to
f0caa50
Compare
r-vasquez
changed the title
PublishMessagePayloadOptions and GenerateSchemaSampleRequest carry the Schema Registry context a schema_id belongs to. Schema IDs are only unique within a context, so the ID is resolved there instead of in the default context. Empty keeps today's behaviour: the topic's redpanda.schema.registry.context is used when set, otherwise the default context.
Console fetched schemas by ID in the default Schema Registry context only, and cached them by ID. Schema IDs are unique per context, so records of a topic bound to a context via redpanda.schema.registry.context failed to decode or, when the default context had the same ID, were decoded with the wrong schema without any error. Producing and the Protobuf message types on subject pages went wrong the same way. Schema lookups now carry the context: the message viewer and produce path read it from the topic config once per request, subject pages take it from the qualified subject name, and clients can name it explicitly. Cache keys include the context. Searching usages by schema ID covers every context. A failed config lookup logs a warning and falls back to the default context.
The message detail's Schema row showed the first subject using a schema ID, which is a subject of the default context even when the topic is bound to another context and the same ID names a different schema there. It now prefers the subject in the topic's context, read from the topic's redpanda.schema.registry.context config. The produce form sends the context of the picked subject along with the schema ID, so the backend encodes with that exact schema. The form offers no schema encodings today, so this only takes effect once they return.
ListMessagesRequest carries a schema_context that names the Schema Registry context to resolve the records' schema IDs in. It takes precedence over the topic's redpanda.schema.registry.context, and "." forces the default context. This covers topics that hold records from a named context without being bound to one. The choice is offered next to the key and value deserializers, only when the registry has contexts, and is kept in the URL (sc) and per topic like the deserializers.
r-vasquez
force-pushed
the
rv/sr-context-aware-schema-resolution
branch
from
September 16, 2026 03:44
f0caa50 to
6ec6a3b
Compare
r-vasquez
enabled auto-merge
September 16, 2026 22:28
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This PR introduces Schema Registry context-aware schema resolution + a fix for a bug.
The schema ID resolution happens in the backend in the following form:
redpanda.schema.registry.contextconfiguration field. (Used by iceberg topics).)Deserialization options for unbounded topics
Before
After
Expanded schema name
Before
After
Bugs:
2 Schemas with the same ID (IDs are unique per context) would resolve to the default context (
.) and fail deserialization:Before
After
Search for Schema ID (2 of them)
Before (only default was shown)
After
