-
Notifications
You must be signed in to change notification settings - Fork 14.5k
KAFKA-19411: Fix deleteAcls bug which allows more deletions than max records per user op #19974
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
Conversation
…s to be returned to user
Thanks for this fix! One problem I see is that this will allow the deletion to partly go through, until we run out of records. It would be better for the deletion to fail completely or succeed completely... |
new RemoveAccessControlEntryRecord().setId(id), (short) 0)); | ||
if (records.size() > MAX_RECORDS_PER_USER_OP) { | ||
// check size limitation first before adding additional records | ||
if (records.size() == MAX_RECORDS_PER_USER_OP) { |
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.
Using >=
would be more future-proof I think...
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.
ack!
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.
LGTM
…records per user op (#19974) If there are more deletion filters after we initially hit the `MAX_RECORDS_PER_USER_OP` bound, we will add an additional deletion record ontop of that for each additional filter. The current error message returned to the client is not useful either, adding logic so client doesn't just get `UNKNOWN_SERVER_EXCEPTION` with no details returned.
…records per user op (#19974) If there are more deletion filters after we initially hit the `MAX_RECORDS_PER_USER_OP` bound, we will add an additional deletion record ontop of that for each additional filter. The current error message returned to the client is not useful either, adding logic so client doesn't just get `UNKNOWN_SERVER_EXCEPTION` with no details returned.
…records per user op (#19974) If there are more deletion filters after we initially hit the `MAX_RECORDS_PER_USER_OP` bound, we will add an additional deletion record ontop of that for each additional filter. The current error message returned to the client is not useful either, adding logic so client doesn't just get `UNKNOWN_SERVER_EXCEPTION` with no details returned. Conflicts: - In AclControlManagerTest.java, use !isPresent instead of isEmpty so that this will work with java 8.
…records per user op (#19974) If there are more deletion filters after we initially hit the `MAX_RECORDS_PER_USER_OP` bound, we will add an additional deletion record ontop of that for each additional filter. The current error message returned to the client is not useful either, adding logic so client doesn't just get `UNKNOWN_SERVER_EXCEPTION` with no details returned. Conflicts: - In AclControlManagerTest.java, use !isPresent instead of isEmpty so that this will work with java 8.
If there are more deletion filters after we initially hit the
MAX_RECORDS_PER_USER_OP
bound, we will add an additional deletionrecord ontop of that for each additional filter.
The current error message returned to the client is not useful either,
adding logic so client doesn't just get
UNKNOWN_SERVER_EXCEPTION
withno details returned.