Skip to content
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

[fix][broker] Fix NPE when set AutoTopicCreationOverride #15653

Merged
merged 1 commit into from May 20, 2022
Merged

[fix][broker] Fix NPE when set AutoTopicCreationOverride #15653

merged 1 commit into from May 20, 2022

Conversation

mattisonchao
Copy link
Member

@mattisonchao mattisonchao commented May 18, 2022

Motivation

When the user wants to set the AutoTopicCreationOverride policy with non-partitioned type, the correct request body is as below.

{
    "allowAutoTopicCreation": true,
    "topicType": "non-partitioned"
}

On the broker side, the request body entity field defaultNumPartitions is null. the NPE will occur when the user sets config maxNumPartitionsPerPartitionedTopic greater than 0.

if (maxPartitions > 0 && autoTopicCreationOverride.getDefaultNumPartitions() > maxPartitions) {
throw new RestException(Status.NOT_ACCEPTABLE,
"Number of partitions should be less than or equal to " + maxPartitions);
}

Modifications

  • Check maxNumPartitionsPerPartitionedTopic just topicType is partitioned

Verifying this change

  • Make sure that the change passes the CI checks.

Add a test testAutoTopicCreationOverrideWithMaxNumPartitionsLimit to verify this change.

Documentation

  • no-need-doc

throw new RestException(Status.NOT_ACCEPTABLE,
"Number of partitions should be less than or equal to " + maxPartitions);
if (Objects.equals(autoTopicCreationOverride.getTopicType(), TopicType.PARTITIONED.toString())) {
if (maxPartitions > 0 && autoTopicCreationOverride.getDefaultNumPartitions() > maxPartitions) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

if the problem is that autoTopicCreationOverride.getDefaultNumPartitions() can be null then we have to simply add a null check and fail the request if it is not passed while maxPartitions is > 0

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A simple null check cannot clearly express why it is null here, which will increase the burden on the maintainers later.
I think a better approach is to use logical judgments to avoid null checks everywhere.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

But you should add the null check anyway. Because here we can fail with NPE

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The null check already exists in bellow code:

public static ValidateResult validateOverride(AutoTopicCreationOverride override) {
if (override == null) {
return ValidateResult.fail("[AutoTopicCreationOverride] can not be null");
}
if (override.isAllowAutoTopicCreation()) {
if (!TopicType.isValidTopicType(override.getTopicType())) {
return ValidateResult.fail(String.format("Unknown topic type [%s]", override.getTopicType()));
}
if (TopicType.PARTITIONED.toString().equals(override.getTopicType())) {
if (override.getDefaultNumPartitions() == null) {
return ValidateResult.fail("[defaultNumPartitions] cannot be null when the type is partitioned.");
}
if (override.getDefaultNumPartitions() <= 0) {
return ValidateResult.fail("[defaultNumPartitions] cannot be less than 1 for partition type.");
}
} else if (TopicType.NON_PARTITIONED.toString().equals(override.getTopicType())) {
if (override.getDefaultNumPartitions() != null) {
return ValidateResult.fail("[defaultNumPartitions] is not allowed to be"
+ " set when the type is non-partition.");
}
}
}
return ValidateResult.success();
}

@Technoboy- Technoboy- closed this May 18, 2022
@Technoboy- Technoboy- reopened this May 18, 2022
@Technoboy- Technoboy- closed this May 18, 2022
@Technoboy- Technoboy- reopened this May 18, 2022
@Technoboy-
Copy link
Contributor

/pulsarbot run-failure-checks

@eolivelli eolivelli merged commit e2afcf0 into apache:master May 20, 2022
codelipenghui pushed a commit that referenced this pull request May 20, 2022
nicoloboschi pushed a commit to datastax/pulsar that referenced this pull request May 23, 2022
)

(cherry picked from commit e2afcf0)
(cherry picked from commit 56ef04c)
shibd added a commit to shibd/pulsar that referenced this pull request May 24, 2022
mattisonchao added a commit that referenced this pull request May 25, 2022
@mattisonchao mattisonchao added the cherry-picked/branch-2.9 Archived: 2.9 is end of life label May 25, 2022
mattisonchao added a commit that referenced this pull request May 25, 2022
@BewareMyPower
Copy link
Contributor

Remove the release/2.8.4 label since it relies on #12322.

@BewareMyPower
Copy link
Contributor

Restore the release/2.8.4 since it looks like #12322 can be cherry-picked to release branches.

BewareMyPower pushed a commit that referenced this pull request Jul 28, 2022
@BewareMyPower BewareMyPower added the cherry-picked/branch-2.8 Archived: 2.8 is end of life label Jul 28, 2022
@Nowadays
Copy link

Does the cherry-picked tags means it has been cherry-picked in the 2.10 version ?

@BewareMyPower
Copy link
Contributor

@Nowadays Yes.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

7 participants