-
Notifications
You must be signed in to change notification settings - Fork 3.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
[Broker] Fix call sync method in async rest api for internalGetMessageById. #13876
[Broker] Fix call sync method in async rest api for internalGetMessageById. #13876
Conversation
}); | ||
}).exceptionally(ex -> { | ||
Throwable cause = ex.getCause(); | ||
if (cause instanceof NullPointerException) { |
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.
it's weird. why we catch NPE here ?
I mean, if somewhere gets NPE, we need to check there. Shouldn't it be catching exceptions?
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.
Yes, maybe we will fix this in another new pr. If fixed here, will be confused.
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.
Agree with you.
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.
Please drop this check.
It is the right time to get rid of this tech debt.
If someone sees the NPE we can fix it.
If we keep this now I bet no one will take care.
It is also possible that that NPE was due to some old bug
I would like to see you dropping this line
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.
Done, This is involved by 6331. Seem that we can drop this line directly.
}); | ||
}).exceptionally(ex -> { | ||
Throwable cause = ex.getCause(); | ||
if (cause instanceof NullPointerException) { |
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.
Please drop this check.
It is the right time to get rid of this tech debt.
If someone sees the NPE we can fix it.
If we keep this now I bet no one will take care.
It is also possible that that NPE was due to some old bug
I would like to see you dropping this line
} | ||
return ret.thenCompose(ignore -> { | ||
return getTopicReferenceAsync(topicName) | ||
.thenAccept(topic -> { |
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.
Do we need to check if the topic is null?
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.
we already checked that the topic is here with validateTopicOwnershipAsync
I am not sure it is needed,
in the old code we did not check for nulls
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.
@codelipenghui If topic does not exist, getTopicReferenceAsync will throw exception.
And I have updated the logic. Thanks for the reminder.
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.
we already checked that the topic is here with validateTopicOwnershipAsync I am not sure it is needed, in the old code we did not check for nulls
getTopicReferenceAsync has checked and I have updated the logic here
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.
+1
} | ||
return ret.thenCompose(ignore -> { | ||
return getTopicReferenceAsync(topicName) | ||
.thenAccept(topic -> { |
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.
we already checked that the topic is here with validateTopicOwnershipAsync
I am not sure it is needed,
in the old code we did not check for nulls
Motivation
Avoid call sync method in async rest API for PersistentTopicsBase#internalGetMessageById.
Documentation
no-need-doc