Skip to content

Conversation

@bosconi
Copy link
Member

@bosconi bosconi commented Dec 31, 2025

Replaced by #34635

Context for my making this PR is here.

When creating a Protobuf source using CONFLUENT SCHEMA REGISTRY
CONNECTION, Materialize fails to compile schemas that import
well-known types like google/protobuf/timestamp.proto. This happens
because the compile_proto function only adds files fetched from the
schema registry to the VirtualSourceTree, but well-known types are
typically not registered in the schema registry (they are implicitly
available to protoc).

This change adds a new protobuf module that embeds the standard
Google protobuf well-known types:

  • any.proto
  • api.proto
  • duration.proto
  • empty.proto
  • field_mask.proto
  • source_context.proto
  • struct.proto
  • timestamp.proto
  • type.proto
  • wrappers.proto

These types are now added to the VirtualSourceTree before compiling
schemas fetched from the schema registry, allowing schemas that import
well-known types to compile successfully.

Motivation

  • This PR fixes a recognized bug.

https://github.com/MaterializeInc/database-issues/issues/10003

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.

bosconi and others added 2 commits December 31, 2025 11:34
When creating a Protobuf source using CONFLUENT SCHEMA REGISTRY
CONNECTION, Materialize previously failed to compile schemas that import
well-known types like google/protobuf/timestamp.proto. This happened
because the compile_proto function only added files fetched from the
schema registry to the VirtualSourceTree, but well-known types are
typically not registered in the schema registry (they are implicitly
available to protoc).

This commit adds a new protobuf module that embeds the standard
Google protobuf well-known types:
- any.proto
- api.proto
- duration.proto
- empty.proto
- field_mask.proto
- source_context.proto
- struct.proto
- timestamp.proto
- type.proto
- wrappers.proto

These types are now added to the VirtualSourceTree before compiling
schemas fetched from the schema registry, allowing schemas that import
well-known types to compile successfully.

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-Authored-By: Claude Opus 4.5 <[email protected]>
Add a test that verifies Materialize can compile Protobuf schemas that
import well-known types (google/protobuf/timestamp.proto,
google/protobuf/duration.proto) even when those types are NOT registered
in the Confluent Schema Registry.

This tests the fix in commit ca7584c where we embed well-known types
in the VirtualSourceTree before compiling CSR schemas.

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-Authored-By: Claude Opus 4.5 <[email protected]>
@bosconi bosconi requested a review from a team as a code owner December 31, 2025 19:14
@bosconi bosconi requested review from def-, ggevay, martykulma, ohbadiah and petrosagg and removed request for ggevay December 31, 2025 19:14
bosconi and others added 2 commits December 31, 2025 14:24
- Reorder mod declarations alphabetically in pure.rs
- Split long method chain in protobuf.rs

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-Authored-By: Claude Opus 4.5 <[email protected]>
Wrap URL in angle brackets to satisfy rustdoc::bare-urls lint.

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-Authored-By: Claude Opus 4.5 <[email protected]>
@bosconi bosconi closed this by deleting the head repository Jan 2, 2026
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