[chore](status) unify error code between thrift,pb, status.h #34397
Conversation
|
Thank you for your contribution to Apache Doris. Since 2024-03-18, the Document has been moved to doris-website. |
|
run buildall |
![github-actions[bot]](https://avatars.githubusercontent.com/in/15368?s=60&v=4){kind=small}
|
run buildall |
|
TeamCity be ut coverage result: |
|
run buildall |
|
TeamCity be ut coverage result: |
|
run buildall |
|
TeamCity be ut coverage result: |
|
run buildall |
|
TeamCity be ut coverage result: |
|
run buildall |
|
TeamCity be ut coverage result: |
|
run buildall |
|
TeamCity be ut coverage result: |
|
run buildall |
|
TeamCity be ut coverage result: |
github-actions
bot
added
the
approved
|
PR approved by at least one committer and no changes requested. |
|
PR approved by anyone and no changes requested. |
|
LGTM |
Co-authored-by: yiguolei <yiguolei@gmail.com>
Because #34397 changed error code of ARITHMETIC_OVERFLOW_ERRROR, so the error msg is not expected in the test.
Because #34397 changed error code of ARITHMETIC_OVERFLOW_ERRROR, so the error msg is not expected in the test.
…34397) Co-authored-by: yiguolei <yiguolei@gmail.com>
6 participants
The problem
Currently, BE use error code in status.h to do error handling. While FE use TStatusCode to do error handling. Sometimes BE will convert status to TStatus and pass to FE. And FE will convert it to TStatusCode, but it may fail because the error code in BE is an int number, and it could not be convert to an ENUM. But we ignore this failure and this is very dangerous. And also FE will send error code to BE such as cancel reason, but be could not get the correct error code.
Proposed changes
In this way, the developer could define an error code in status.h with error code > 0, it could be passed to FE and FE could convert it to TStatusCode. And also FE could set an error code using TStatusCode and pass to BE, and BE could convert it to status.
In next PR, I will remove PFragmentCancelReason.
Further comments
If this is a relatively large or complex change, kick off the discussion at dev@doris.apache.org by explaining why you chose the solution you did and what alternatives you considered, etc...