Daml Connect 1.18.0 has been released. You can install it using:
daml install 1.18.0
actAs
and readAs
party sets, and Daml Script can now use submitMulti
even if no token for the exact set of parties used is specified.
Impact and Migration
--use-pre-1.18-error-codes
. The improved error codes contain changes to status codes and error messages. A migration guide is available in the documentation.--static-time
flag.Background
To create a better development experience when writing robust client applications for Daml, error codes have been improved throughout the development stack. The enhancements make error codes easier to interpret and uncover the root cause of the problem, standardize error codes across different Daml drivers to further improve the portability of Daml applications, and make applications easier to operate and debug in production environments.
Specific Changes
max_deduplication_duration
as part of the metadata sent with the gRPC return status.
Impact and Migration
Most commercial Daml Drivers, specifically Daml for VMware Blockchain and Canton-based drivers, will only support the new error codes in new versions. To make the transition from development to production as smooth as possible, the Sandbox and Daml Driver for PostgreSQL 1.18 will also use the new error codes by default. However, both the Sandbox and Daml Driver for PostgreSQL 1.18 will maintain backward compatibility via the command line flag --use-pre-1.18-error-codes
.
This cleanup of error codes and messages has resulted in a number of status and message changes. To switch to the new codes, please consult the migration guide for details.
Background
Multi-party submissions were introduced to Daml to aid with a range of use-cases around read delegation, reference data sharing, and role-based access controls. They allow a Ledger API client to specify an authentication token with multiple parties in actAs
and readAs
lists to act or read simultaneously as more than one party. Refer to the original blog post for details.
Making use of these features via the JSON API is now easier. Up until now the JSON API inferred the actAs
and readAs
lists from the provided token. This meant that in situations where one wanted to act with restricted party sets - for example for safety reasons - individual tokens for each party set needed to be published. With this improvement, the party set used can now be narrowed down as part of the JSON API request which means it is sufficient to have one access token for all parties in use.
This is used by the Daml Script to allow running submitMulti
via the JSON API even if the token specified doesn’t exactly match the submission, but only specifies a superset of the parties used.
Specific Changes
actAs
and readAs
lists may be specified for create, exercise, create-and-exercise, non-WS fetch, and non-WS queries in the JSON API. See here for more information in the documentation.submit p
works even if you have a token with actAs = [p, p2]
.
Impact and Migration
This is an additive change except for some sample code for Triggers. As part of this change testRule
gained an extra argument to specify the readAs
parties. If you previously used
testRule trigger party acsBuilder commandsInFlight s
you now need to use
testRule trigger party [] acsBuilder commandsInFlight s
Background
Some contention errors are easy to detect and can be resolved by retrying. For example, consider a write-read collision on contract keys, where one command changes a contract key - by archiving a contract with that key and creating a new one - and another command resolves that key. If the reading command resolves the key before the writing command is committed, but is committed second, it will fail because it’s trying to access an archived contract. Retrying the command to re-resolve the key can be sufficient to succeed.
To make it easier to deal with this case - one of the most common types of contention errors - the Ledger API is now able to automatically retry command interpretation a number of times in cases where such a collision is detected before the transaction is sent to the underlying ledger.
Specific Changes
Impact and Migration
Contention errors are reduced. In cases where contention occurs, a command may succeed with increased latency instead of returning an error quickly.
Background
In order to reduce the development time and effort needed to deploy, maintain and monitor a Daml Connect application we have created a Helm chart to start all of the Connect components in a robust, secure, and highly available fashion on a Kubernetes cluster. The setup also offers easier management and observability aggregation over deploying individual components. This new feature, in alpha stage, is now available as part of the Daml Connect Enterprise Edition.
Specific Changes
Impact and Migration
This is an additive change which Daml Connect Enterprise users are encouraged to evaluate for their environment.
--min-tls-version
Follow the guidance in the JSON API CLI (eg daml json-api --help
) help for specifics.
react
library as a peer dependency. React v.17 will be accepted in addition to the current React v.16. For new projects, the create-daml-app
template now uses React 17.multiplexQueryStreams
flag set to `false` to use the previous behavior (opening one WebSocket for each transaction stream).debugRaw
has been added as a convenience wrapper around traceRaw
when used inside a do-block. The new debugRaw
syntax compares to debug
like traceRaw
compares to trace
, meaning it expects a Text
instead of calling show
on an expression. This means that the resulting trace message will not be wrapped in quotes and special characters will not be escaped.--max-inbound-message-size
flag for increasing the maximum size of messages transmitted via the gRPC API. This is useful for uploading or downloading large DARs via the PackageService.CompletionResponse
when available.--ledger-readas a,b,c
. create-only
, create-if-needed-and-start
, create-and-start
).matchedQueries
field in the WebSocket response to be incorrect in a few edge cases.