-
Notifications
You must be signed in to change notification settings - Fork 8.9k
bugfix: fix order() behavior in GlobalTransactionalInterceptorHandler to ensure correct sorting of invocation handlers #7570
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
…ionalInterceptorHandler (apache#7563)
YongGoose
left a comment
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.
Nice work!
Left some comments.
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.
Is there a specific reason why order method wasn’t implemented in AbstractProxyInvocationHandler?
IMO, Implementing order in AbstractProxyInvocationHandler would allow us to take advantage of inheritance.
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 observed that both SagaAnnotationActionInterceptorHandler and TccActionInterceptorHandler, which inherit from AbstractProxyInvocationHandler, explicitly override the order() method.
To maintain consistency and clarity across all subclasses, I felt it would be more appropriate for GlobalTransactionalInterceptorHandler to do the same, rather than relying on a shared implementation in the abstract class.
Of course, if you believe it would be better to introduce a shared order() implementation in the abstract class, I'm more than happy to follow that direction.
I'm open to adjusting the PR according to your preference or the maintainers' conventions.
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 believe adding it to the abstract class would be a better approach, as this way the subclasses aren’t forced to implement it explicitly through inheritance.
| @Override | ||
| public int getOrder() { | ||
| return this.order; | ||
| return this.order(); |
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.
Is there a reason why the order function needs to return?
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.
You're right — the line should return the order field directly instead of calling this.order(). I will update the code accordingly to return the order field as you suggested !
|
Thank you for the review! Let me summarize the feedback as I understand it:
@Override
public int order() {
return this.order;
}
@Override
public int order() {
return this.order;
}→ With this, all classes implementing
@Override
public int getOrder() {
return this.order;
}One thing I noticed is that both the Please let me know if this approach looks good to you. I’ll proceed accordingly once I hear back from you. |
Since the original issue was that |
|
Additionally, for the tests, it would be good to declare multiple classes inheriting from |
|
When work is done, Don't hesitate to ping me :) |
|
Thank you again for the detailed feedback!
Please feel free to take another look when you have time. |
YongGoose
left a comment
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 resolve the conflicts.
|
Ok, I resolved! |
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## 2.x #7570 +/- ##
=========================================
Coverage 61.30% 61.30%
Complexity 658 658
=========================================
Files 1311 1310 -1
Lines 49567 49568 +1
Branches 5834 5834
=========================================
+ Hits 30385 30388 +3
+ Misses 16461 16460 -1
+ Partials 2721 2720 -1
🚀 New features to boost your workflow:
|
# Conflicts: # changes/en-us/2.x.md # changes/zh-cn/2.x.md
|
Thank you for the earlier feedback 🙏
This should ensure that the ordering logic in |
YongGoose
left a comment
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 🚀
Also, I'd appreciate it if you could revise the parts mentioned in the comments :)
.../java/org/apache/seata/integration/tx/api/interceptor/parser/DefaultInterfaceParserTest.java
Outdated
Show resolved
Hide resolved
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.
Pull Request Overview
This PR fixes the ordering behavior of invocation handlers in the Seata framework by ensuring that the order() method correctly returns the handler's order value for proper sorting. The fix addresses an issue where GlobalTransactionalInterceptorHandler was not being sorted correctly despite having order values set through setOrder() and getOrder() methods.
- Removed the default implementation of
order()method fromProxyInvocationHandlerinterface, making it abstract - Added proper
order()method implementations inAbstractProxyInvocationHandlerandGlobalTransactionalInterceptorHandler - Changed the default order value from
Integer.MAX_VALUEto0inAbstractProxyInvocationHandler
Reviewed Changes
Copilot reviewed 6 out of 6 changed files in this pull request and generated 1 comment.
Show a summary per file
| File | Description |
|---|---|
| ProxyInvocationHandler.java | Removed default order() implementation to make it abstract |
| AbstractProxyInvocationHandler.java | Added order() implementation and changed default order value to 0 |
| GlobalTransactionalInterceptorHandler.java | Added order() method implementation |
| DefaultInterfaceParserTest.java | Added comprehensive test cases to verify handler ordering behavior |
| changes/zh-cn/2.x.md | Updated Chinese changelog with fix description |
| changes/en-us/2.x.md | Updated English changelog with fix description |
.../org/apache/seata/integration/tx/api/interceptor/handler/AbstractProxyInvocationHandler.java
Outdated
Show resolved
Hide resolved
.../org/apache/seata/integration/tx/api/interceptor/handler/AbstractProxyInvocationHandler.java
Outdated
Show resolved
Hide resolved
…tx/api/interceptor/handler/AbstractProxyInvocationHandler.java Co-authored-by: funkye <[email protected]>
|
The TCC transaction propagation test is failing. |
...ache/seata/integration/tx/api/interceptor/handler/GlobalTransactionalInterceptorHandler.java
Outdated
Show resolved
Hide resolved
…tx/api/interceptor/handler/GlobalTransactionalInterceptorHandler.java
I think the order of the test cases has changed again, which caused this issue. You can see that the exception started appearing right after this PR was merged: https://github.com/apache/incubator-seata/actions/runs/16847550947/job/47731890204 |
funky-eyes
left a comment
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
|
If you're using the DingTalk app, please send your DingTalk account to my email at |
… to ensure correct sorting of invocation handlers (apache#7570)
… to ensure correct sorting of invocation handlers (apache#7570)
Ⅰ. Describe what this PR did
This PR fixes the incorrect sorting behavior of
GlobalTransactionalInterceptorHandlerinDefaultInterfaceParser.parserInterfaceToProxy().Although the
orderfield was being set usinggetOrder()andsetOrder(), it was not being reflected in the sorting logic due to the lack of an overriddenorder()method.The fix ensures that all
ProxyInvocationHandlerimplementations, includingGlobalTransactionalInterceptorHandler, are sorted based on the intendedordervalue.Ⅱ. Does this pull request fix one issue?
fixes #7568
This fixes the handler ordering inconsistency described in the related issue.
Ⅲ. Why don't you add test cases (unit test/integration test)?
Ⅳ. Describe how to verify it
Ⅴ. Special notes for reviews