Why isn't there an archive node in the transaction graph on a (consuming) choice

Questions
2

Transaction trees in DAML (both in the transaction tree service as well as in the transaction graph in DAML Studio) only know about 4 types of nodes:

  1. Create
  2. Exercise (consuming and non-consuming)
  3. Fetch (not exposed in the transaction tree service atm)
  4. LookupByKey (not exposed in the transaction tree service atm)

There is no Archive node here. So how does archiveCmd cid or exerciseCmd cid Archive work? The DAML compiler automatically generates a consuming choice called Archive with the signatories as the controllers for every template.

So the only way to archive a contract is to call a consuming choice and that’s exactly what you are seeing here: In the first example you only see the exercise of the consuming Transfer1 choice. In the second example, you see the exercise of the nonconsuming Transfer2 choice which as a consequence exercises the consuming Archive choice injected by the compiler. In neither of those examples do you see a node representing the actual archive.

Now there are imho 2 issues here that we should address:

  1. In the short term, the transaction graph in DAML Studio should indicate which choices are consuming and which are nonconsuming.
  2. In the long term, we should imho try to change the primitives. Instead of having consuming and nonconsuming choices, only provide nonconsuming choices and a primitive for archiving. If needed, you can still have syntactic sugar in the compiler similar to how we have the preconsuming keyword atm. As a basis, archive + nonconsuming choices is much easier to grasp imho than consuming + nonconsuming.
4 Likes