# io.grpc.Status vs com.google.rpc.Status

**URL:** <https://forum.canton.network/t/io-grpc-status-vs-com-google-rpc-status/2281>\
**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:** 1\
**Showing post:** 3

<div class="post-metadata">

**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")

</div>

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

---

_[View the full topic](https://forum.canton.network/t/io-grpc-status-vs-com-google-rpc-status/2281)._