Order of GRPC errors with command deduplication

Questions
, ,
1

Hello all,

I’m currently working in a project where we are implementing command deduplication under a BE that we are running. We are facing a situation with concurrent BEs capturing the same event with milliseconds of diference and executing an exercise command with such a time delay.
The first command goes through successfully with its specific changeId but the second one even though it has the same changeId it returns a CONTRACT_NOT_FOUND error instead of a DUPLICATE_COMMAND or SUBMISSION_ALREADY_IN_FLIGHT.
For further context, choice that is being executed is consuming and it left me wondering if the CONTRACT_NOT_FOUND error takes precedence of the deduplication errors when being received in the command submission service. Is this the case?

Best regards

2 Likes
2

Hi David,

my understanding is that you are trying to implement command deduplication to prevent multiple client applications from submitting the same command.

If this understanding is correct, the answer is the following:

Command deduplication is meant to prevent one client application from submitting the same command several times, not different ledger applications from submitting the same command.

The change ID, which must be identical between several submissions in order to trigger command deduplication, is a triple which contains the application ID. Consequently, if different applications submit otherwise identical commands, the submissions will not have the same change ID, so command deduplication is not triggered.

See the relevant chapter of the Daml docs:

If you want to make sure that an intended ledger change is not executed twice, your application needs to robustly handle all failure scenarios

How Command Deduplication Works

The following fields in a command submissions are relevant for command deduplication. The first three form the change ID that identifies the intended ledger change.

  • The union of party and act_as define the submitting parties.
  • The application ID identifies the application that submits the command.
  • The command ID is chosen by the application to identify the intended ledger change.

See Command Deduplication.

Regards
Gyorgy

3

Hello Gyorgy,

Apologies if I didn’t express myself correctly.
The change id is the exact same for both transactions, so the second which should be considered a duplicate, right?

Best regards

4

Hi David,

the explanation for the seemingly inconsistent error messages is that 1) there are several checks performed by Canton, and 2) with retry, the ledger state can change between tries, and a different message can be returned depending on whether the first request is committed at the time of the second request or not.

The practical consequence for you is that you can expect both kinds of error messages.

Some more details:

  1. Contract activeness checking happens first (in the ledger-api server). Failures to find a contract (e.g. because of archival) result in CONTRACT_NOT_FOUND.

  2. Assuming step 1 has not resulted in errors, command deduplication checking happens. A duplicate change ID results in SUBMISSION_ALREADY_IN_FLIGHT

I hope this clarifies for you what happens.

Regards

Gyorgy

@oliverse thank you for clarifying this.

2 Likes
5

Hello Gyorgy,

Thank you for your reply, indeed it does clarify my question

Best regards