What is the possible completionStreamResponse Status Code and how to handle them

Questions
,
1

I’m listening to the command completion service and trying to understand how to handle the returned result.
Question 1:

In Ledger API, does it use all the grpc status code?
https://developers.google.com/maps-booking/reference/grpc-api/status_codes

Question 2:
Which status code indicates that the transaction has been committed and no need to retry?
e.g. OK, ALREADY_EXISTS …

Below is the code I use to get the status

Disposable t = response.subscribeWith(new DisposableSubscriber<CompletionStreamResponse>(){
            @Override
            public void onNext(CompletionStreamResponse completionStreamResponse) {
                completionStreamResponse.getCompletions()
                        .forEach(completion -> {
                            if (completion.getStatus().equals(Status.OK)){
                                commandSubmissionQueue.remove(completion.getCommandId());
                            }
                            logger.info(
                                    "Completion for cid:{}/party:{}/Status:{}/{}",
                                    completion.getCommandId(),
                                    party,
                                    completion.getStatus().getCode(),
                                    Status.fromCodeValue(completion.getStatus().getCode()).getCode().ordinal()
                            );
                        });
            }
1 Like
2

Not all of them, but we do try to map error conditions to sensible conditions. The ones that apply more broadly you’ll likely see the most (apart from OK) are INVALID_ARGUMENT when the request parameters don’t pass validation or if a command fails during execution (e.g. you’re trying to use a consumed contract), PERMISSION_DENIED if you are interacting with a Ledger API that verifies authorization and RESOURCE_EXHAUSTED if the system back-pressure thresholds are hit.

The command completion service returns you the status of commands that have successfully passed validation and deduplication. It contains no information about transactions, which are provided by the transaction service, either as a stream of contract state changes (“flat transactions” in Ledger API parlance) or as a stream of transaction trees containing all create and exercise events (“transaction trees” for short, within the context of the Ledger API).

If you’re interested in evaluating whether a command has been blocked before deduplication, you have to check the command submission service, which indeed returns ALREADY_EXISTS if the command could not be successfully submitted due to deduplication.

2 Likes
3

The docs imply that all gRPC status codes are possible. Use the Ledger API With gRPC — Daml SDK 2.7.6 documentation

These docs also specify what to expect from each of the Ledger API-specific status codes @Frankie