feat(error): preserve error's source chain across gRPC boundary

[BugenZhao]

I hereby agree to the terms of the RisingWave Labs, Inc. Contributor License Agreement.

What's changed and what's your intention?

Recursively encode the error and its sources into into a data struct, filling it into the details field of tonic::Status, then propagate it through the wire to the gRPC client and extract the source chain there with TonicStatusWrapper. This follows the practice of the gRPC error handling guide.

Organize the utilities into a new crate risingwave_error to draw a clear distinction with the error handling pattern in risingwave_common::error that's going to be deprecated.

The idea goes back to #4227 (comment).

Preview

risingwave/e2e_test/error_ui/main.slt

Lines 13 to 20 in c37d889

	statement error
	alter system set not_exist_key to value;
	----
	db error: ERROR: QueryError
	Caused by these errors (recent errors listed first):
	1: gRPC request to meta service failed: Internal error
	2: SystemParams error: unrecognized system param "not_exist_key"

Checklist

• I have written necessary rustdoc comments
• I have added necessary unit tests and integration tests
• All checks passed in ./risedev check (or alias, ./risedev c)

Documentation

• My PR needs documentation updates. (Please use the Release note section below to summarize the impact on users)

Release note

If this PR includes changes that directly affect users or other significant modifications relevant to the community, kindly draft a release note to provide a concise summary of these changes. Please prioritize highlighting the impact these changes will have on users.

[xxchan]

Generally LGTM. Cool!

Could you please construct a real example in RisingWave where the err msg is improved? 🤪

[xxchan]

ExprError => InvalidArgument doesn't look very correct 🤣

BTW, I was always wondering whether we should map application error code to tonic status code.. This is like the debate whether to use HTTP status code or simply use it as a wrapper and do everything in the payload. I don't have an answer. Just want to mention it. Let's just keep it until somebody is unhappy.

[BugenZhao]

I agree. I just leave the behavior unchanged in this PR. 😕

whether we should map application error code to tonic status code.

+1. And the only place we refer to it is the error message of Status. 😄

[BugenZhao]

Could you please construct a real example in RisingWave where the err msg is improved? 🤪

I'll show you after #13264 and risinglightdb/sqllogictest-rs#200 🥰

[codecov]

Codecov Report

Merging #13282 (c37d889) into main (117f14c) will increase coverage by 0.00%.
Report is 3 commits behind head on main.
The diff coverage is 66.66%.

@@           Coverage Diff            @@
##             main   #13282    +/-   ##
========================================
  Coverage   67.74%   67.74%            
========================================
  Files        1524     1525     +1     
  Lines      259435   259553   +118     
========================================
+ Hits       175762   175847    +85     
- Misses      83673    83706    +33     

Flag	Coverage Δ
rust	67.74% <66.66%> (+<0.01%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

Files	Coverage Δ
src/frontend/src/scheduler/error.rs	8.33% <ø> (ø)
src/stream/src/executor/error.rs	22.98% <ø> (ø)
src/batch/src/error.rs	0.00% <0.00%> (ø)
src/meta/src/hummock/error.rs	5.55% <0.00%> (ø)
src/meta/src/model/error.rs	0.00% <0.00%> (ø)
src/rpc_client/src/error.rs	33.33% <50.00%> (ø)
src/storage/src/filter_key_extractor.rs	84.14% <0.00%> (ø)
src/stream/src/error.rs	0.00% <0.00%> (ø)
src/prost/src/lib.rs	88.09% <0.00%> (-2.15%)	⬇️
src/meta/src/error.rs	26.13% <0.00%> (ø)
... and 2 more

... and 7 files with indirect coverage changes

📣 Codecov offers a browser extension for seamless coverage viewing on GitHub. Try it in Chrome or Firefox today!