Allow for rollback of sub-transactions within DAML workflow

A cursory review of the business requirements for production DAML projects suggests that >90% of any given workflow is specifying exceptional workflows to handle business constraint violations.

At the present point in time, DAML only permits a single response to a business constraint violation: abort the current transaction in its entirety. Unfortunately, this leaves the system in an invalid state, as the business requirement is for the workflow to transition to an error handling/recovery state, and this would require updating the ledger—something that is currently impossible once an abort has been triggered.

What is needed is the ability to ‘catch’ the abort at a sub-transaction level, and then proceed with an alternative ledger-update. It is anticipated that this would end up looking something along the lines of MonadError.

Worth noting that:

• This is not an asynchronous exception capability, specifically:
• Failures of fetchBy, fetch, key-uniqueness violations, exercises on inactive cids are all contention failures only detectable at post-sequence validation, not business constraint violations, so do not interact with this feature
• ensuring violations and assert/abort violations do represent business constraint violations, and so should interact with this feature
• This would entail requiring assert/abort to take any instance of Show as an argument.
• Update a, would now become a right-biased Update e a
• If the exception remains uncaught at the outer transaction, then the behaviour remains identical to the current behaviour, except for an implicit call to show e go obtain a string

Note: Our experience to date suggests that any non-trivial, real-world, multi-party workflow requires this functionality.

[filmackay]

Thanks for raising @andrae-da I was just about to raise this Issue after discussing with @neil-da last night! I see this as splitting current failures into two classes:

• aborts: fetch/exercise failures => cannot be caught - remains as-is. Akin to a SQL database deadlock victim.
• errors: everything else - arithmetic overflow, div-by-zero, asserts, thrown errors (what we currently call abort). Akin to any other kind of error in a SQL database.

We’re not trying to introduce any non-determinism, but simply handle the deterministic failures (what I’ve called errors, above).

[cocreature]

this is covered as part of exceptions in daml-lf 1.14