這個案例的核心責任是提供「consumer 對收到的錯誤能信多少」的一手根據：同一個 code、兩個可能的產生者。

觀察

gRPC status codes guide 列 17 個 code、明確標注「Only a subset of the pre-defined status codes are generated by the gRPC libraries」。只由 user code 產生（library 從不產生）的 code：INVALID_ARGUMENT、NOT_FOUND、ALREADY_EXISTS、FAILED_PRECONDITION、ABORTED、OUT_OF_RANGE、DATA_LOSS。UNAVAILABLE 標為「most likely a transient condition, which can be corrected by retrying with a backoff」、但對非冪等操作要小心。

判讀

client 收到 UNAVAILABLE、DEADLINE_EXCEEDED、INTERNAL 時、無法單從 code 分辨是 server 應用回的、還是中間 channel 或 library 自己產生的 —— 只有那 7 個「library 從不產生」的 code 能確定來自 server 邏輯。中間服務轉發錯誤時原樣透傳 UNKNOWN 或 INTERNAL、等於把「產生者是誰」的資訊消滅掉。這直接支撐「provider 暴露多少 vs consumer 能信多少」：錯誤的可信度不是均質的、契約設計要讓 consumer 分得出哪些 code 承載應用語意。

對應大綱

11.11 錯誤鏈傳播章「consumer 對收到的錯誤能信多少」段；UNAVAILABLE 的 retry 判讀連接收方重試決策章。

下一步路由

回 模組十一案例庫。

引用源