Ordering of events within a transaction on flat transaction stream

Hi,
I’m wondering if there are any guarantees on the ordering of events in the flat transaction stream at com.daml.ledger.api.v1.TransactionService.

Consider the following example:

1. I have a template with a contract key and one contract of that template.
2. In a transaction, I now archive that contract and create a new one with the same key. The ordering matters here. If I first create the new one and then archive the existing contract, the transaction fails.

Am I guaranteed to see the archive before the create in the list of events?

Excellent question. The answer depends on your relationship to the contract and key, the Ledger’s consensus policies, and the Ledger’s topology. So the answer in general is “no”, but it’s “yes” when it matters.

Let’s first of all see how this can fail:

Let’s say Alice is hosted on participant P and participant P is connected to two domains/partitions A and B.

1. A contract C of type T with key K exists in A.
2. A transaction TX1 is committed in A through which Alice witnesses the archival of C
3. A transaction is TX2 committed on B through which Alice witnesses the creation of C’ of type T with key K

If the consensus algorithm in A and B is such that P’s confirmation is not needed for TX1, and P’s connection to A is slow, it could happen that P receives TX2 before TX1. You now get the create before the archive.

So when is it guaranteed that the archive comes before the create?

• If the archive and create are causality ordered in Alice's projection. Eg if Alice is a maintainer of K, or if Alice witnesses a consuming choice on C that creates C'.
• If the create and archive happen on the same domain/partition, and that domain/partition give a total order to transactions. This applies in particular to all non-partitioned DAML ledgers currently in existence.
• If the archive and create happen in the same transaction.

In other words, the scenario above illustrates the the circumstances required to not get this guarantee:

• A Ledger which guarantees only causality ordering (eg multi-domain partitioned topology)
• A Participant which is not involved in the consensus of the transactions in question

Great answer, thank you! However, I think you might have misunderstood my question. In my example, the create and archive both happen within a single transaction. I’m asking about the ordering of the events list in a transaction not the ordering of transactions.

Oh, in that case the answer is a simple “yes”. Every transaction is an ordered forest of actions. All parties that witness any part of the transaction get events according to that ordering.

Follow on question re this - if I submit a list of commands in a CommandsSubmission batch, and each of these commands is a CreateAndExercise command that creates a new contract, so say the batch is [Cmd1, Cmd2, Cmd3], then in the single Transaction that I receive as a response on the flat Tx stream, am I guaranteed to get the following events in the exact order?

[Create-1-Cmd1, Archive-1-Cmd1, Create-2-Cmd1, 
Create-1-Cmd2, Archive-1-Cmd2, Create-2-Cmd2,
Create-1-Cmd3, Archive-1-Cmd3, Create-2-Cmd3]

Yes. Commands in a single submission are executed atomically (ie all or nothing) in the given order.

Cheers, thanks @bernhard