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(3.2): triple AbstractServerCallListener NPE #14009

Merged
merged 2 commits into from
Apr 7, 2024
Merged

Conversation

caoyanan666
Copy link
Contributor

@caoyanan666 caoyanan666 commented Mar 29, 2024

What is the purpose of the change

NPE bug fix

Brief changelog

image
response.getValue is null, onReturn(null) will throw Serialize triple response failed NPE

Verifying this change

Checklist

  • Make sure there is a GitHub_issue field for the change (usually before you start working on it). Trivial changes like typos do not require a GitHub issue. Your pull request should address just this issue, without pulling in other changes - one PR resolves one issue.
  • Each commit in the pull request should have a meaningful subject line and body.
  • Write a pull request description that is detailed enough to understand what the pull request does, how, and why.
  • Check if is necessary to patch to Dubbo 3 if you are work on Dubbo 2.7
  • Write necessary unit-test to verify your logic correction, more mock a little better when cross module dependency exist. If the new feature or significant change is committed, please remember to add sample in dubbo samples project.
  • Add some description to dubbo-website project if you are requesting to add a feature.
  • GitHub Actions works fine on your own branch.
  • If this contribution is large, please follow the Software Donation Guide.

@codecov-commenter
Copy link

codecov-commenter commented Mar 29, 2024

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 70.41%. Comparing base (00812ce) to head (2fb2f3b).
Report is 5 commits behind head on 3.2.

Additional details and impacted files
@@            Coverage Diff             @@
##              3.2   #14009      +/-   ##
==========================================
- Coverage   70.43%   70.41%   -0.03%     
==========================================
  Files        1607     1607              
  Lines       70074    70097      +23     
  Branches    10100    10103       +3     
==========================================
  Hits        49356    49356              
- Misses      16080    16095      +15     
- Partials     4638     4646       +8     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

Copy link
Member

@AlbumenJ AlbumenJ left a comment

Choose a reason for hiding this comment

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

LGTM

@AlbumenJ
Copy link
Member

AlbumenJ commented Apr 2, 2024

@icodening @EarthChen PTAL

Comment on lines 71 to 74
if (r.hasException()) {
doOnResponseHasException(r.getException());
return;
}
Copy link
Contributor

Choose a reason for hiding this comment

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

in this case, why response.hasException is false?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

因为直接invoke的response是同步执行的结果,whenCompleteWithContext里面回调的response是异步的AppResponse,只要provider的实现用了异步,在实际的异步结果里面有异常,就会是外面Invoker的response没异常,whenCompleteWithContext回调的appResponse有异常

Because the response of direct invoke is the result of synchronous execution, the response of the callback in whenCompleteWithContext is an asynchronous AppResponse. As long as the provider implementation uses asynchronous, if there is an exception in the actual asynchronous result, it will be because the response of the external Invoker is not abnormal, and the callback of whenCompleteWithContext is appResponse has exception

Copy link
Contributor

Choose a reason for hiding this comment

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

嗯嗯,那这样看来使用r.hasException()替换掉原来的response.hasException()应该会更好,因为r才是最终真实的结果

Copy link
Contributor Author

Choose a reason for hiding this comment

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

OK,我改一下

Copy link

sonarcloud bot commented Apr 7, 2024

@AlbumenJ AlbumenJ requested a review from icodening April 7, 2024 06:15
@icodening icodening merged commit 95439fb into apache:3.2 Apr 7, 2024
19 checks passed
Will-well pushed a commit to Will-well/dubbo that referenced this pull request Apr 9, 2024
* fix NPE

* Optimize the handling of exceptions in response

---------

Co-authored-by: caoyanan <caoyanan@growingio.com>
@@ -62,14 +62,18 @@ public void invoke() {
final long stInMillis = System.currentTimeMillis();
try {
final Result response = invoker.invoke(invocation);
if (response.hasException()) {

Choose a reason for hiding this comment

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

我想问下这边考虑调用一下 hasException 的原因是啥

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

Successfully merging this pull request may close these issues.

None yet

5 participants