Release of Daml 2.9.4

Summary

This is a maintenance release that addresses several issues.

What’s New

Canton

• Canton protocol version (PV) 6 is now demoted to ‘Unstable’ from ‘Beta’.  There are several challenging fixes that are being added to the Smart Contract Upgrade Beta feature.  Backwards compatibility is not guaranteed for these fixes so the PV is moved from ‘Beta’ to ‘Unstable.’  There are detailed bug descriptions below for the open issues related to PV 6.
• Minor improvements in Canton around DAR upload validation.

Daml Language and IDE

• Fixed a bug in daml-script where submission by parties imported via getUser were targeting the wrong participant in a multi-participant setting.
• Interpolation of environment variables in daml.yaml has been extended to support yaml keys.
• Improved “go to definition” and hovering for record constructors in Daml Studio.
• Improved “go to definition” between packages in multi-package projects.
• Updated Daml Studio to work with Visual Studio Code version 1.92 and above.
• Improved Java code generation to prevent rare name clashes.
• Improved the support for smart contract upgrades in the IDE ledger.
• Minor improvements to error messages around smart contract upgrades.

PQS and Daml Shell

• Added additional latency metrics
• Added a sample Grafana dashboard to display several PQS metrics.
• Fixed a bug where PQS /livez endpoint would not respond outside of a connection.
• PQS and Daml Shell now display comprehensive version and compatibility information (see --version).
• Enhanced PQS to better handle packages in Daml-LF version 1.16.
• Resolve a bug in Daml Shell that could cause a deadlock when it received rapid terminal input from automation tooling.

Daml Finance

• Fixed a bug in the `Daml.Finance.Holding` package affecting the `Disclosure.I` implementation of the `Factory` template within the `Daml.Finance.Holding.Factory` module.

Detailed Beta Feature Bug Descriptions

Following are detailed bug descriptions for the Beta features of Canton protocol version (PV) 6 and the Smart Contract Upgrade (SCU) feature.  They can only occur if the steps to enable Beta features SCU and PV 6 have been taken; they cannot occur otherwise. They are in the process of being fixed for a future release.

Critical Bug: Use of `fetch` on interfaces can fork the ledger

When a transaction view contains a call to `fetch @I` targeting an interface I of an interface that is not used in an exercise anywhere in the same view, an error is thrown during re-interpretation as part of validation : “cannot resolve package <package-name>”

This breaks deterministic validation. In most circumstances this will lead to unexpected command failures with errors (`LOCAL_VERDICT_FAILED_MODEL_CONFORMANCE_CHECK`). However, should the affected node be in an observer role only, that error may not actually lead to a command rejection. In that case, the observing node will sound the alarm and fork from the submitting node(s).

Critical Bug: Use of `fromInterface` can fork the ledger

When a transaction view contains a call to `fromInterface @T` targeting a template T of a version that does not match what the Interface value was created from (either manually built, or as from package-preference when using `fetch`) , then the call may erroneously return `None` instead of the expected `Optional (cid, args)` during re-interpretation as part of validation.

This breaks deterministic validation. In most circumstances this will lead to unexpected command failures with alarming errors (`LOCAL_VERDICT_FAILED_MODEL_CONFORMANCE_CHECK`). However, should the affected node be in an observer role only, that error may not actually lead to a command rejection. In that case, the observing node will sound the alarm and fork from the submitting node(s).

Critical Bug: Missing packages result in rejections

When a transaction contains an action on a contract created in version A, but a receiving node doesn’t have package version A, it will reject the transaction. 

This breaks deterministic validation. In most circumstances this will lead to unexpected command failures with alarming errors (`LOCAL_VERDICT_FAILED_MODEL_CONFORMANCE_CHECK`). However, should the affected node be in an observer role only, that error may not actually lead to a command rejection. In that case, the observing node will sound the alarm and fork from the submitting node(s).

Bug: Missing Upgrade Validation for DARs with multiple versions

When uploading a DAR with both V1 and V2 of a package, the participant doesn't compare the two versions for upgrade compatibility. Consequently the participant may load and vet the packages even though they are not compatible. Behavior of the engine when presented with two versions of a package that are not actually compatible is unspecified. The system will most likely crash at runtime, but it might be possible that some unspecified behavior could even provoke a ledger fork or leak information.

Limitation: Contract key types cannot be upgraded

This is a limitation more than a bug, but lifting the limitation requires a backwards breaking protocol upgrade. In 2.9.1, the type of a contract key cannot be changed, ever.  If template Foo is defined in package A version 1, and the key type of Foo is defined in package B version 1, then the key type of the upgraded Foo in version 2 also has to depend on B version 1. So A version 2 has to depend on B versions 1 and 2 which is quite annoying to manage.

Download and Installation 

The Daml 2.9.4 SDK has been released. You can install it using the command: daml install 2.9.4.

The table below lists how you can download Daml Enterprise or individual components.

If you are using Oracle JVM and testing security provider signatures, note that the Canton JAR file embeds the Bouncy Castle provider as a dependency. To enable the JVM to verify the signature, put the bcprov JAR on the classpath before the Canton standalone JAR. For example:

java -cp bcprov-jdk15on-1.70.jar:canton-with-drivers-2.9.4-all.jar com.digitalasset.canton.CantonEnterpriseApp

Note: These Docker images are designed to be suitable for production use, with minimal size and attack surface. Minimal images can sometimes make debugging difficult (e.g. no shell in the containers). For convenience, we provide “debug” versions of each of the above images, which you can access by appending “-debug” to the image tag (e.g. digitalasset-docker.jfrog.io/http-json:2.9.4-debug).