😽

GRPCで標準以外のカスタムエラーを利用したい場合

2022/10/18に公開

GRPCのカスタムエラー

先日の仕事でgRPCのカスタムエラーについて確認したのでメモ

gRPCのエラーは17種類のメッセージがあります。
しかし実際のサービス運用で、404 だけどこの場合とこの場合でフロント側の処理を変えたいから何か判定返したいな。。。なんてことありませんか?
https://grpc.io/docs/guides/error/

この場合は「grpc-status-details-bin」という箇所に詳細を入れることがよさそうです。

実際にテストコードを見てみたのですが確かにそのようなコードが見受けられました

    it 'decodes proto values' do
      rpc_status = Google::Rpc::Status.new(
        code: 1,
        message: 'matching message',
        details: [simple_request_any, simple_response_any, payload_any]
      )
      rpc_status_proto = Google::Rpc::Status.encode(rpc_status)

      code = 1
      details = 'details'
      metadata = { 'grpc-status-details-bin' => rpc_status_proto }

      exception = GRPC::BadStatus.new(code, details, metadata)

      expect(exception.to_rpc_status).to eq rpc_status
    end

https://github.com/grpc/grpc/blob/2d4f3c56001cd1e1f85734b2f7c5ce5f2797c38a/src/ruby/spec/errors_spec.rb#L106-L121
ここに格納する値はBase64でエンコードされているため、取り出す際は注意してください

ただし、利用には注意が必要でこの実装はgRFCで使えるのですが、特に文書化されていないことを下記のissueで指摘されています。
https://github.com/grpc/grpc/issues/24007

This field is currently a supported feature of gRPC but its design / behavior is entirely undocumented. We need a specification for this feature to refer to users and to verify that our implementations are correct and complete. Unfortunately, since the current implementations (C/Java/Go/others?) were done without a spec/gRFC in place, we need to make sure the spec allows for all their behaviors.

考察

基本は17種類のエラーに合わせて、'grpc-status-details-bin'は極力使わずにクライアントのエラーも用意するべきかな〜とメンバーと議論しました。
特に実ユーザーに行動を促す際に詳細なエラー必要ですかね〜?あまり必要じゃないかなと考えています。もしこのあたり意見ある方いたらコメントいただけると嬉しいです。

参考

コチラの記事が大変参考になりました
https://zenn.dev/hsaki/books/golang-grpc-starting/viewer/errorcode
https://qiita.com/nozmiz/items/4b33d41d6b77e85a0e85

Discussion