-
Notifications
You must be signed in to change notification settings - Fork 13.6k
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-8988. Replace CreatePartitions Request/Response with automated protocol #7493
Merged
hachikuji
merged 5 commits into
apache:trunk
from
soondenana:CreatePartitionsAutotmatedProtocol
Jan 8, 2020
Merged
Changes from all commits
Commits
Show all changes
5 commits
Select commit
Hold shift + click to select a range
d2e4a57
KAFKA-8988. Replace CreatePartitions Request/Response with automated …
soondenana 9e0143a
Take care of review comments
soondenana 7e51140
Change ErrorMessage default to null
soondenana 6d469f0
Take care of latest round of review comments
soondenana 0128e03
Don't filter out empty partition reassignment
soondenana File filter
Filter by extension
Conversations
Failed to load comments.
Jump to
Jump to file
Failed to load files.
Diff view
Diff view
There are no files selected for viewing
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
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
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
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
Oops, something went wrong.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Leaving this here for lack of an alternative. I was looking at the defaults used in the schema definitions. We do not override them in any cases, but I wonder if it would make sense in the case of
validateOnly
. If we do not override, the default would befalse
, but maybetrue
is a safer value?Another thing I was looking at is how we handle the
ErrorMessage
field in the response. The previous serialization logic usedApiError
which attempts to avoid serialization when the error message matches the standard value. I suspect that we might have broken this optimization in other cases as well, though I'm not sure how much it matters. Also, the old code used null as the default instead of the empty string. Perhaps we should do the same?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree that its safer to have
validateOnly
default totrue
, but I think the common case is to have itfalse
. If I am user of this api, I will assume the api call to create partitions by default. And if there is a need for validation only, only then I will look deeper into api to find a flag for doing that. So in that sense it matches user expectation.Interesting comment about the
ErrorMessage
. But when creatingCreatePartitionsResponse
inCreatePartitionsRequest::getErrorResponse
, we useapiError.message
to populate the error message, and the method returns null if the message is default. It seems if we useapiError.messageWithFallback
then we will get into situation that you are describing. I may be missing something here.Updated json to set
null
forErrorMessage
field. Thanks for pointing that out.