# io.grpc.Status vs com.google.rpc.Status **URL:** \ **Category:** App Development\ **Tags:** ledger-api\ **Created:** [March 16, 2021, 2:42am UTC](https://forum.canton.network/t/io-grpc-status-vs-com-google-rpc-status/2281 "2021-03-16T02:42:35Z")\ **Posts on this page:** 6\ **Page:** 1
**Author:** ![zoraizmahmood](https://yyz2.discourse-cdn.com/flex034/user_avatar/forum.canton.network/zoraizmahmood/32/1401_2.png) [@zoraizmahmood](https://forum.canton.network/u/zoraizmahmood)\ **Post date:** [March 16, 2021, 2:42am UTC](https://forum.canton.network/t/io-grpc-status-vs-com-google-rpc-status/2281/1 "2021-03-16T02:42:36Z")
Hello! It seems that LedgerAPI status messages and error messages can be handled in different ways depending on the library you use. My understanding is that the LedgerApi is built on gRPC, which is why I initially thought it would be more appropriate to use `io.grpc.Status` over `com.google.rpc.Status`, but it seems that `com.google.rpc.Status` is the native status type returned by the CompletionService. - CommandClient: - using _submit_ with a _blockingGet:_ - returns _Empty_ on success - throws _Throwable_ on failure - → can be converted to _io.grpc.Status_ using _io.grpc.fromThrowable(throwable)_ - → can be converted to _com.google.rpc.Status_ using _io.grpc.protobuf.StatusProto.fromThrowable(t)_ - using _submit_ with an _Observer:_ - onSuccess: returns _Empty_ - onError: returns _Throwabl_ e - → can be converted to _io.grpc.Status_ using _io.grpc.fromThrowable(throwable)_ - → can be converted to _com.google.rpc.Status_ using _io.grpc.protobuf.StatusProto.fromThrowable(t)_ - CommandSubmissionClient: - using _submit_ with an Observer: - returns _Empty_ on success - throws _Throwable_ on failure - → can be converted to _io.grpc.Status_ using _io.grpc.fromThrowable(throwable)_ - → can be converted to _com.google.rpc.Status_ using _io.grpc.protobuf.StatusProto.fromThrowable(t)_ - CommandCompletionClient: - subscribed to _completionStream_ with an Observer: - returns _com.google.rpc.Status_ , which is contained in the CompletionStreamResponse - _com.google.rpc.Status_ can be converted to _io.grpc.Status_ by using _getCode()_ and _getMessage()_ then building _io.grpc.Status.fromCodeValue().withDescription()_ - _io.grpc.Status_ can be converted back to _com.google.rpc.Status_ using _com.google.rpc.Status.newBuilder().setCode().setMessage().build()_ **Questions** : - Will using either of the libraries result in different description messages? - Is there a recommended approach which should be used? We were previously using _io.grpc.Status_ and had to do conversion to _com.google.rpc.Status_. Thanks! -Zoraiz ---
**Author:** ![stefanobaghino-da](https://yyz2.discourse-cdn.com/flex034/user_avatar/forum.canton.network/stefanobaghino-da/32/7057_2.png) [@stefanobaghino-da](https://forum.canton.network/u/stefanobaghino-da)\ **Post date:** [March 16, 2021, 1:11pm UTC](https://forum.canton.network/t/io-grpc-status-vs-com-google-rpc-status/2281/2 "2021-03-16T13:11:20Z")
Please note that the two `Status` classes cover different errors. `io.grpc.Status` represents the success or failure of a call at a service level: a failure stems from an invalid argument, hitting an overloaded endpoint, and so on. In the specific context of the command completion service, `com.google.rpc.Status` is the code generated for the Protobuf message that describes whether a command was executed successfully or not, and for what reason. To make a specific example, you can make a call to the completion service that returns successfully (`io.grpc.Status`) and get a stream of completed commands, which can either have succeeded or failed (`com.google.rpc.Status`). I would not try to convert between those two classes but use each at the relevant layer to address failures: you can for example have a retry strategy for calls that fail because of back-pressure on the Ledger API (`io.grpc.Status`) and a separate one to retry to issue specific commands that may have failed (`com.google.rpc.Status`). ---
**Author:** ![zoraizmahmood](https://yyz2.discourse-cdn.com/flex034/user_avatar/forum.canton.network/zoraizmahmood/32/1401_2.png) [@zoraizmahmood](https://forum.canton.network/u/zoraizmahmood)\ **Post date:** [March 17, 2021, 1:58am UTC](https://forum.canton.network/t/io-grpc-status-vs-com-google-rpc-status/2281/3 "2021-03-17T01:58:20Z")
Hi Stefano, Thanks for the response! I just have a few questions that stem from your response. **Q1**. You mention that `com.google.rpc.Status` is used in the specific context of the Command Completion Service stream of completed commands. Would it be safe to imply that in every other context, we should be using `io.grpc.Status`? **Q2**. Having done some toying with the Command Service and the Command Completion Service, I found that having submitted a request using the Command Service, one could expect a response from the Command Completion Service if they were subscribed. This validated my understanding that the Command Service is a wrapper of the Command Submission Service and the Command Completion Service. With this in mind, if a transaction was submitted to the Command Service and failed, for example due to an assertion failure during execution, would we expect the same gRPC Error Code and Error Message in the Command Completion Service? This would be unusual considering I would handle an error from the Command Service using `io.grpc.Status`, whereas I would be using `com.google.rpc.Status` for the Command Completion Response. Are we guaranteed to have the same error description/message? **Q3.** More on the topic of Command Service as a wrapper of the Command Submission Service and Command Completion Service. Based on the Command Service documentation: [daml/command\_service.proto at cda93db944afe55d987ba8b7d5326e256ae359cf · digital-asset/daml · GitHub](https://github.com/digital-asset/daml/blob/cda93db944afe55d987ba8b7d5326e256ae359cf/ledger-api/grpc-definitions/com/daml/ledger/api/v1/command_service.proto) , we see that there is a `RESOURCE_EXHAUSTED` error return if the number of in-flight commands reaches a maximum, and we have a limit set, which is also confirmed by Robert in [When is RESOURCE\_EXHAUSTED returned by the command submission/completion services? - #2 by Robert\_Autenrieth](https://discuss.daml.com/t/when-is-resource-exhausted-returned-by-the-command-submission-completion-services/1570/2) . From our own research using Daml on VMWare Blockchain (VMBC), we have identified two other scenarios where RESOURCE\_EXHAUSTED occurs: backpressure on client nodes, backpressure on replicas. Would the ‘in-flight’ commands issue imply there is a third scenario under which RESOURCE\_EXHAUSTED might occur and is this exclusive to the Command Service? Thank you! Zoraiz ---
**Author:** ![stefanobaghino-da](https://yyz2.discourse-cdn.com/flex034/user_avatar/forum.canton.network/stefanobaghino-da/32/7057_2.png) [@stefanobaghino-da](https://forum.canton.network/u/stefanobaghino-da)\ **Post date:** [March 17, 2021, 6:47am UTC](https://forum.canton.network/t/io-grpc-status-vs-com-google-rpc-status/2281/4 "2021-03-17T06:47:03Z")
> [@zoraizmahmood](#): > > **Q1**. You mention that `com.google.rpc.Status` is used in the specific context of the Command Completion Service stream of completed commands. Would it be safe to imply that in every other context, we should be using `io.grpc.Status` ? For clarity: `com.google.rpc.Status` is used in the context of the command completion service to model an answer _in the response_. `io.grpc.Status` is not part of a response, it represents the status of the service call. I hope this clarifies. ---
**Author:** ![stefanobaghino-da](https://yyz2.discourse-cdn.com/flex034/user_avatar/forum.canton.network/stefanobaghino-da/32/7057_2.png) [@stefanobaghino-da](https://forum.canton.network/u/stefanobaghino-da)\ **Post date:** [March 17, 2021, 6:48am UTC](https://forum.canton.network/t/io-grpc-status-vs-com-google-rpc-status/2281/5 "2021-03-17T06:48:29Z")
> [@zoraizmahmood](#): > > This would be unusual considering I would handle an error from the Command Service using `io.grpc.Status` , whereas I would be using `com.google.rpc.Status` for the Command Completion Response. Are we guaranteed to have the same error description/message? In the case of the command service, a failed command will be wrapped in a failed service call, so you can expect that. The error message should be the same as the one you would see if you received the command status on the completion service. ---
**Author:** ![stefanobaghino-da](https://yyz2.discourse-cdn.com/flex034/user_avatar/forum.canton.network/stefanobaghino-da/32/7057_2.png) [@stefanobaghino-da](https://forum.canton.network/u/stefanobaghino-da)\ **Post date:** [March 17, 2021, 6:49am UTC](https://forum.canton.network/t/io-grpc-status-vs-com-google-rpc-status/2281/6 "2021-03-17T06:49:38Z")
> [@zoraizmahmood](#): > > Would the ‘in-flight’ commands issue imply there is a third scenario under which RESOURCE\_EXHAUSTED might occur and is this exclusive to the Command Service? Yes, in-flight means that the command has been submitted but an answer has not yet been received on the command completion service, so it only applies to the command service.