Status returned from duplicated command

Questions
,
1

Hi,

I was trying the deduplication features on DAML on (Concord) ledger and it seems that there is an issue.

The test was done on two participant nodes and the two nodes belongs to the same logical group i.e. replicated

  1. Command c is created and submitted to node 1 with command id. The submission status is OK and Completion status is also OK.
  2. The same command id is used to submit the command again to node 1. The submission status is ALREADY_EXIST (no need to wait completion status)
  3. The same command id is used to submit the command to node 2. The submission status is OK but no Completion status was returned (I waited for about an hour and later found out that the command was not executed on the ledger.)

It seems step 3 should return ALREADY_EXIST from submission or completion. Otherwise the client won’t be able to tell exactly what has happened to the command.

2 Likes
2

Hi Frankie,

Your observation is correct:

  • Commands deduplicated by the same participant return the ALREADY_EXISTS error on command submission
  • Commands deduplicated across participants are silently dropped.

We are aware of the confusing user experience. In the near future, we will be looking into improving command deduplication, after carefully checking the impact on existing applications.

To give some background on the current implementation:

  • Commands are deduplicated at two levels: at participant level, and at ledger level (across participants).
  • The second level is optional. Not all ledgers support cross-participant command deduplication.
  • For different reasons, we do not generate rejection updates for commands deduplicated by the ledger. Before changing this, we will need to carefully analyze the impact. Among others, it could confuse applications, as they would start seeing multiple Completion statuses (OK followed by ALREADY_EXISTS) for the same command ID.
3 Likes
3

@Robert_Autenrieth Thanks for checking that. Looking forward to the coming change.

Depends on the requirement, the client implementation could be different. The commands I have here are order sensitive and the client I build waits for response from completion stream before sending the next command. It will get it eventually but the time spent on waiting and resubmitting can be saved.

1 Like