Refactoring: Refactoring the Result Class

[YongGoose]

Why you need it?

Please check the comments on the PR.

• feature: migrate the console to the naming server #7157 (comment)

How it could be?

I want to use type effectively in the Result object, just like in SimpleResult.

One idea I have is to move APIs like success from SimpleResult to Result.

[YongGoose]

@funky-eyes

I’d like to proceed once both tasks are completed.
Please assign me to this issue.

Thank you! ☺️

• optimize seata-client TM&RM netty eventloop #6774
• feature: Implement scheduled handling for end status transaction #7133

[funky-eyes]

Well done, looking forward to your PR.

[YongGoose]

@xingfudeshi

If you're interested, please review PR I created 🙂

• refactor: Refactoring the Result Class #7176

[xingfudeshi]

@xingfudeshi

If you're interested, please review PR I created 🙂

• refactor: Refactoring the Result Class #7176

Sure!

[funky-eyes]

I want to know which modules are currently involved in refactoring and the classes involved, as we need to understand the scope of this issue.

[YongGoose]

I want to know which modules are currently involved in refactoring and the classes involved, as we need to understand the scope of this issue.

I refactored the Result class along with its subclasses.
Consequently, the common, console, namingserver, and server modules, which depend on these classes, were also part of the refactoring.

[funky-eyes]

OK, I believe the impact of this change is within a controllable range. You can complete this change through multiple PRs, either by module or by dependency.

[YongGoose]

OK, I believe the impact of this change is within a controllable range. You can complete this change through multiple PRs, either by module or by dependency.

Is it correct to address the impact of this PR through multiple PRs?
If I’ve misunderstood, could you please provide further clarification?

[funky-eyes]

OK, I believe the impact of this change is within a controllable range. You can complete this change through multiple PRs, either by module or by dependency.

Is it correct to address the impact of this PR through multiple PRs? If I’ve misunderstood, could you please provide further clarification?

Yes, you can gradually complete the refactoring through multiple PRs.

[YongGoose]

Yes, you can gradually complete the refactoring through multiple PRs.

Whenever you have time, could you create an issue related to this?
I’d also really appreciate it if you could add it as a sub-issue under the main one. 🙂

[YongGoose]

@funky-eyes

If you could clarify which specific areas this PR affects, I'll review it and create an issue before proceeding with the work.
I'm still not sure which areas this PR affects. 😅

[funky-eyes]

I see that you've submitted a PR, but I'm not quite sure what exactly you need me to confirm or check for you.

[YongGoose]

I see that you've submitted a PR, but I'm not quite sure what exactly you need me to confirm or check for you.

You mean the PR or the comment?

[YongGoose]

@funky-eyes

For the PR, I have refactored the Result class according to the discussion we had in the comments.

• feature: migrate the console to the naming server #7157 (comment)

Please review that part when you get a chance.

Also, in your comment, you mentioned that my PR affects other parts, but I wasn’t sure exactly which areas you were referring to. Could you clarify which parts are impacted?

• Refactoring: Refactoring the Result Class #7158 (comment)

[funky-eyes]

My point is that, based on the scope of changes you described (the Seata module), the impacted areas appear to be within the expected scope.