Daml 2.6.0 release candidate has been released. You can install it using:
daml install 2.6.0
Release 2.6.0 brings a wide range of improvements to identity provider integration, observability, and Daml Finance, as well as new event querying APIs in early access. Some security enhancements are also included.
BESU_VERSION_MISMATCH
error if they are not met.Daml’s APIs use Json Web Token (JWT)-based authentication. The tokens are issued by an external identity provider (IDP).
The new Identity Provider Config Service makes it possible for participant node administrators to set up and manage additional identity providers at runtime. This allows using access tokens from identity providers unknown at deployment time. When an identity provider is configured, independent IDP administrators can manage their own set of parties and users.
Such parties and users have a matching identity_provider_id
defined and are inaccessible to administrators from other identity providers. A user will only be authenticated if the corresponding JWT token is issued by the appropriate identity provider. Users and parties without identity_provider_id
defined are assumed to be using the default identity provider, which is configured statically when the participant node is deployed..
CreateIdentityProviderConfig
request.DeleteIdentityProviderConfig
request.UpdateIdentityProviderConfig
request.ListIdentityProviderConfigs
request.GetIdentityProviderConfig
request. identity_provider_id
field to a number of requests of the Party Management Service.AllocatePartyRequest
, allowing a party to be created within the scope of a particular identity providerGetPartiesRequest
, UpdatePartyDetails
, in these requests the identity_provider_id
field in the request must match the value assigned at creation timeListKnownPartiesRequest
, allowing to narrow the query to within the scope of a given participant identity provideridentity_provider_id
field to the PartyDetails
record returned in the AllocatePartyResponse
, UpdatePartyDetailsResponse
, GetPartiesResponse
and ListKnownPartiesResponse
messages used in the Party Management Service.IdentityProviderAdmin
to the User Management Service. It allows designating a particular user as responsible for administering the identity provider that the user is assigned to. The designated user is able to manage other users and parties that are also assigned to the same identity provider.identity_provider_id
field to the User message within the User Management Service. It signifies the id of the identity provider configured by Identity Provider Config. This message is part of several requestsCreateUserRequest
, allowing a user to be created within the scope of a particular identity providerGetUserRequest
, UpdateUserRequest
, DeleteUserRequest
, GrantUserRightsRequest
, RevokeUserRightsRequest
, ListUserRightsRequest
, in these requests the identity_provider_id
field in the request must match the value assigned at creation timeListUsersRequest
, allowing to narrow the query to within the scope of a given participant identity provideridentity_provider_id
field to the User record returned in the CreateUserResponse
, GetUserResponse
, UpdateUserResponse
and ListUsersResponse
messages used in the User Management Service.This is a purely additive change.
Best practice for monitoring a microservices application is an approach known as the Golden Signals or the RED method where metrics monitoring determines whether the application is healthy and, if unhealthy, which service or endpoint (i.e. API) is the root cause of the issue. This release is the General Availability of the Golden Signals for HTTP and gRPC endpoints. It also includes other key metrics.
The Golden Signal metrics for each HTTP and gRPC API are available:
The labels that accompany each metric can be used for filtering or aggregation. The instrumentation labels added to each HTTP API metric are:
http_verb
: HTTP verb (e.g., GET, POST).http_status
: Status code (e.g., 200, 401, 403, 504).host
: Host identifier. daml_version
: Daml release number.service
: A string to identify what Daml service or Canton component is running in this process (e.g., participant
, domain
, json_api
, etc.). In case several Canton components run in a single process, domain is reported.path
: The request made to the endpoint (e.g., /v1/create
, /v1/exercise
).The gRPC protocol is layered on top of HTTP/2, hence we include certain labels such as the daml_version
and service
from the above section. The labels that are added by default to each gRPC API metric are:
canton_version
: Canton protocol version. grpc_code
: Human readable status code for gRPC (e.g. OK, CANCELLED, DEADLINE_EXCEEDED).grpc_client_type
and grpc_server_type
.grpc_service_name
and grpc_method_name
.Other key metrics that are monitored are:
maxDirtyRequests
is close to being hit. The metrics are: canton_dirty_requests
and canton_max_dirty_requests
.The updated metrics documentation now provides a categorization as: Latency, Traffic, Errors, Saturation or Debug. As a general rule users are advised to avoid monitoring the Debug metrics as they are considered internal and may disappear or change meaning in subsequent versions.
All other metrics reporters except Prometheus were deprecated (see full list here).
Before | After |
daml.http_json_api.command_submission_timing |
Extract from daml_http_requests_duration_seconds histogram matching labels {path=~”/v1/create|/v1/exercise|/v1/create-and-exercise”} |
daml.http_json_api.query_all_timing |
Extract from daml_http_requests_duration_seconds histogram matching labels {path=”/v1/query”,http_verb=”GET”} |
daml.http_json_api.query_matching_timing |
Extract from daml_http_requests_duration_seconds histogram matching labels {path=”/v1/query”,http_verb=”POST”} |
daml.http_json_api.fetch_timing |
Extract from daml_http_requests_duration_seconds histogram matching labels {path=”/v1/fetch”} and {path=”/v1/parties”,http_verb=”POST”} |
daml.http_json_api.get_party_timing |
Extract from daml_http_requests_duration_seconds histogram matching labels {path=”/v1/parties”,http_verb=”GET”} |
daml.http_json_api.allocate_party_timing |
Extract from daml_http_requests_duration_seconds histogram matching label {path=”/v1/parties/allocate”} |
daml.http_json_api.download_package_timing |
Extract from daml_http_requests_duration_seconds histogram matching labels {path=~”/v1/packages/.+”} |
daml.http_json_api.upload_package_timing |
Extract from daml_http_requests_duration_secondshistogram matching labels {path=~”/v1/packages”,http_verb=”POST”} |
daml.http_json_api.http_request_throughput |
daml_http_requests_total |
daml.http_json_api.command_submission_throughput |
daml_http_requests_total{path=~”/v1/create|/v1/exercise|/v1/create-and-exercise”} |
daml.http_json_api.upload_packages_throughput |
daml_http_requests_total{path=~”/v1/packages”,http_verb=”POST”} |
daml.http_json_api.allocation_party_throughput |
daml_http_requests_total{path=”/v1/parties/allocate”} |
The metrics below should instead use the metrics that are now available in common gRPC endpoint metrics:
Before | After |
daml.lapi.<service_method> |
daml_grpc_server_duration_seconds{grpc_service_name=<service_name>,grpc_method_name=<service_method} |
daml.lapi.return_status.<gRPC_status_code> |
daml_grpc_server_handled_total{grpc_status_code=<gRPC_status_code>} |
The metrics below should instead use the metrics that are now available in common JVM execution service metrics:
The following mapping should be used:
Before | After |
<threadpool name>.completed |
daml_executor_runtime_completed{name=<threadpool name>} |
<threadpool name>.duration |
daml_executor_runtime_duration_seconds{name=<threadpool name>} |
<threadpool name>.idle |
daml_executor_runtime_idle_duration_seconds{name=<threadpool name>} |
<threadpool name>.running |
daml_executor_runtime_running{name=<threadpool name>} |
<threadpool name>.submitted |
daml_executor_runtime_submitted{name=<threadpool name>} |
For example, to migrate the metric daml.index.db.threadpool.connection.indexer.completed
you would instead reference daml_executor_runtime_completed{name=daml.index.db.threadpool.connection.indexer}
in your PromQL query.
The following metrics were removed because they were intended for development only and not for public use:
Daml Finance has gained new functionality for financial modeling.
List of packages declared stable, early access, deprecated in 2.6.0 can be found here.
The Active Contract Service is designed to allow client applications to bootstrap faster by providing a recent state snapshot. Updates to that snapshot can then be streamed through the transaction service.
Until now, the offset at which the snapshot is provided was given by the participant node, with the only constraint being that it is “recent”. That means that in order to get a historic view of the ledger state a client application had to either stream from the ledger beginning or apply transaction effects backwards to the recent snapshot.
With this addition, client applications can request state snapshots for any offsets after the last pruning offset, which means it is much easier to recover historic states.
active_at_offset
field to the GetActiveContractsRequest
. It defines an offset at which the snapshot of the active contracts will be computed. The requested offset must be equal to or greater than the last pruning offset and no greater than the ledger end. This is a purely additive change.
archive_event
will be unset.continuation_token
returned in the GetEventsByContractKeyResponse
in a subsequent GetEventsByContractKeyRequest
.GetEventsByContractId
request. GetEventsByContractKey
request. This is a purely additive change.
{
"aud": ["https://example.com/non/related/audience", "https://daml.com/jwt/aud/participant/someParticipantId"],
"sub": "someUserId",
"exp": 1300819380
}
--target=1.14
or similar in your daml.yaml file.GetMeteringReportResponse
.GetLatestPrunedOffsets
request. It allows querying for current pruning offsets.will-corrupt-your-system-dev-version-support
under canton.domains.<domain>.init.domain-parameters has been removed. Now setting protocol-version to an unstable version (i.e. dev) requires you to explicitly enable canton.parameters.non-standard-config = yes.will-corrupt-your-system-dev-version-support
and unsafe-enable-daml-lf-dev-version
under canton.participants.<participant>.parameters
have been removed. Now use the new flag canton.participants.<participant>.parameters.dev-version-support
to both enable participant connectivity to unstable protocol version domains and to turn on support for unsafe Daml-LF dev versions. Using this option requires you to explicitly enable canton.parameters.non-standard-config = yes
.maxBurstFactor * maxRate
commands above the maxRate
. This will reduce the likeliness of undesired backpressure rejects caused by small and temporary bursts.resources.set_resource_limits
.sequencer.parameters.max-burst-factor = 0.5
(default).canton.monitoring.health.check.participant
to canton.monitoring.health.check.node
. This is a backwards compatible change."--rpc-http-api=WEB3,..."
).BESU_VERSION_MISMATCH
error if they are not met.max-event-age
metrics. Refer to the documentation overview and details.replication.set_passive
command is now also supported on a remote participant setup.UNKNOWN_SUBMITTERS
and SUBMITTERS_NOT_ACTIVE
mimic the already existing UNKNOWN_INFORMEES
and INFORMEES_NOT_ACTIVE
messages, respectively reporting if any submitter is not known at all and if no domain can be found where all submitters are hosted and active.-Dio.netty.transport.noNative=true
system property setting.daml test
. Refer to the updated tutorial. Improved coverage and counting of interface choices.requires
. This can improve type information when casting. See the reference documentation for interfaces..trigger.metrics
blocks. The evaluation metrics include statistics such as the number of submissions a rule emits and the time a rule evaluation takes.`DateClock`
implementation to avoid key uniqueness violation errors `advance`
and `rewind`
in the `Reference.Time`
interface