refactor(api/base): name the message queue option topic_keys#264
Open
behinddwalls wants to merge 1 commit into
Open
refactor(api/base): name the message queue option topic_keys#264behinddwalls wants to merge 1 commit into
behinddwalls wants to merge 1 commit into
Conversation
The message queue topic-binding option carries a stable LOGICAL topic key, not a concrete wire name: each implementer maps the key to whatever topic name its broker/queue requires (subject to that backend's naming constraints), and our Go wiring maps it via consumer.TopicRegistry. Rename the option topics -> topic_keys (E_Topics -> E_TopicKeys) and reframe its doc accordingly. Field number 50001 is unchanged, so the wire/extension layout is identical.
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.
Summary
Why?
The message queue topic-binding proto option was named
topics, which reads as a concrete wire topic name. It is not — it carries a stable logical topic key. Each implementer maps the key to whatever topic name its broker/queue requires (subject to that backend's naming constraints); on our Go side the keys areconsumer.TopicKeyvalues, mapped to concrete names throughTopicRegistry. The nametopicsinvited the wrong mental model.What?
Rename the
google.protobuf.MessageOptionsextensiontopics→topic_keys(field number50001unchanged, so the wire/extension layout is identical) and reframe its doc comment to say it carries a logical key, not a wire name. Regeneratedmessagequeue.pb.go(E_Topics→E_TopicKeys).This is the base of a stack; the runway contract and the contract RFC that consume the option are updated in the branches stacked on top.
Test Plan
✅
make proto— descriptor field renamed (name=topics→name=topic_keys), field number50001unchanged✅
./tool/bazel build //...Issues
Stack