fix: prevent name collisions between messages and services #107
Conversation
This file contains 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
If a service has the same name as a message, we suffix the service name with "Service.
We may want to rename the test and baseline files to be more informative: .1-message.1-service, .2-message.1-server, 1.-message.2-server
alexander-fenster
approved these changes
Dec 1, 2023
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Previously, a Discovery
schemaand aresourcethat differed only in casing would result in a protomessageandservice, respectively, with the same upper-camel-case name in the same namespace. This would cause downstream problems when attempting to parse the proto.We now disambiguate such cases by suffixing the names of such conflicting services with
Service.We explicitly do NOT deal with recursive disambiguation. That is, if the first disambiguation attempt between a message and a service fails, we do not attempt to find a different suffix to continue the disambiguation. If needed, we can add this later, but for the moment it seems a good idea to flag such occurrences.