Multi domain transaction

Questions
,
1

Hello,

I’m facing an issue when performing a transaction with a multi domain canton setup.
The architecture is as follows:

Participant A (PA) -> Domain 1 (D1) <- Participant B (PB) -> Domain 2 (D2) <- Participant C (PC)

Additional setup:

  • PB has multi domain support configured
  • A dar with a template Foo was uploaded to all participants
  • A dar with a template Bar was uploaded to PB
  • Template Bar has a choice that takes as parameters a contract for template Foo coming from PA (fooPAcid) and another coming from PC (fooPCcid).
  • Neither Foo contract’s stakeholders have visibility on Bar with the exception of the Bar’s choice controller, which is an observer on both Foos

Now the problem:
Executing this choice with only a fetch for fooPAcid succeeds the transaction, as does executing it with a fetch of fooPCcid, but if I have both fetches I get the following error.

FAILED_PRECONDITION: INFORMEES_NOT_ACTIVE(9,0f1df11e): There is no common domain where all informees are active

What is the reason for this error in this context?

Thanks in advance

2 Likes
2

A fetch is a ledger event as it represents a liveness check. So if you have a fetch fooPACcid and a fetch fooPCcid in the same transaction, then you have a ledger event which is visible to PA, and a ledger event which is visible to PC in the same transaction. But there is no sync domain on which both PA and PC are both present, so no place where this transaction could be synchronized.

3

It’s still a bit unclear to me, unfortunately. Why can’t PA and PB synchronise the fooPACcid fetch and PC, PB synchronise the other fetch independently, since PA and PC don’t need to know about one another?

4

Each Daml transaction is synchronized against exactly one domain, that’s important so you can guarantee it being atomic. So if you do both fetches in the same transaction you are forcing a single domain and as Bernhard explained there is no suitable one in your example. If you do the fetches independently you get two separate transactions that can use different sync domains each.

5

Just out of curiosity, is the single domain synchronization something that is leftover from before multi-domain transactions were possible, and is subject to change, or is there no foreseeable future where this would be changed?

6

Multi domain mostly allows one participant node to be able to connect to several domains. For a given contract, the stakeholders of that contract can then decide which domain they want to use to synchronize changes on that contract (archive or exercise a choice).

Note that even with multi domain being enabled, you’ll get the behavior that was described above. If one transaction needs several contracts as input, then they will first all be reassigned to a domain (in particular, you need to have a domain that hosts all the stakeholders of all the input contracts), and then the transaction is submitted on that domain.

One possible evolution of the protocol that would remove the need of this shared domain is “cross domain transactions”, but there are no plans for this yet.

3 Likes
7

Okay, thank you for the clarifications