R3 Docs R3 Docs Home

Corda 5.2 Release Notes heading-link-icon

Corda 5.2.2 is a patch release of Corda focused on improving Corda resiliency. This page lists the key changes in the 5.2.2 release of Corda and contains the following:

The Corda 5.2.2 patch release contains bug fixes and also improves Corda clusters’ resiliency to Kafka errors. It also includes improvements to the Corda self-reporting health mechanism. Consequently, migrating to 5.2.2 from 5.2.1 can be done via a rolling upgrade. It should only require updating worker software versions via a Helm chart upgrade command to 5.2.2. Then workers can be scaled down to zero replicas and scaled back up to the desired replica count to pick up the new image.

You cannot upgrade from 5.1 directly to 5.2.2. Instead, 5.1 customers must upgrade to version 5.2 using the 5.2 upgrade process and then upgrade to version 5.2.1 using the 5.2.1 upgrade instructions. Following that they should follow the upgrade instructions for 5.2.2. For information about upgrading a Corda cluster, see:

Corda enforces a maximum payload size for messages sent to the Kafka message bus. This limit is configurable in the corda.messaging section of the Corda configuration file via the maxAllowedMessageSize field.

Validation mechanisms have been introduced in the following areas to ensure that user data does not exceed the maximum allowable message size.

The Flow Start request is limited to a maximum of 50% of the maxAllowedMessageSize. This restriction accounts for field duplication in subsequent payloads within the system. If a client attempts to start a flow that exceeds this size, an error is returned, and the flow does not start.

The External Messaging API, already present in Corda 5.2, allows sending messages directly to the Kafka topics. If a flow attempts to send a message exceeding the maxAllowedMessageSize, a CordaRuntimeException is thrown within the flow.

The result of a flow returned by the ClientStartableFlow API is transmitted directly to the message bus as part of the flow status update. Validation has been implemented to ensure that the result does not exceed the maxAllowedMessageSize. If this validation fails, the flow is marked as failed.

  • Improved resiliency to Kafka connection interruptions.
  • Improved error handling while consumer group is rebalancing. A CommitFailedException error is now recoverable without restarting a worker.
  • Improved recovery methods for producers which have been fenced due to ProducerFencedException.
  • Resolved issue where a worker in an unhealthy state can report as healthy via worker’s /isHealthy REST endpoint.
  • Resolved issue where flow worker topic partitions can become blocked due to retries of transient errors for a subset of flows.

Corda 5.2.1 is a patch release of Corda focused on resolving issues. This page lists the key changes in the 5.2.1 release of Corda and contains the following:

Corda 5.2.1 patch release contains bug fixes and introduces the ability to perform disaster recovery operations on a single cluster network. To support this, there are updates to the database schema and Kafka topic configurations. Consequently, migrating to 5.2.1 involves more than just updating worker software versions via a Helm chart upgrade command. A more complex migration path is required, and thus 5.2.1 has its own set of upgrade instructions.

You cannot upgrade from 5.1 directly to 5.2.1. Instead, 5.1 customers must upgrade to version 5.2 using the 5.2 upgrade process and then upgrade to version 5.2.1 using the 5.2.1 upgrade instructions. For information about upgrading a Corda cluster, see:

This section describes the enhancements made in 5.2.1.

A new upgrade command has been added to the Corda CLI tool. You can use this command to migrate data as part of the platform upgrade process from version 5.2 to 5.2.1.

For more details about the upgrade Corda CLI command, see upgrade.

This section describes the issues resolved in 5.2.1.

  • If administrative data on Kafka is lost or becomes out of sync, it is automatically restored from the database. An issue where this process did not work properly has been fixed.
  • Fixed integration between REST worker and state manager so that different state types are not stored within the same schema when configured to not do so. As a consequence, previous flow status records might become inaccessible after an upgrade.

This section describes known issues persisting in 5.2.1.

  • Changing the configuration can interrupt reconciliation (the process of aligning mismatches of data in the database with Kafka) inside the database worker. Pods can theoretically restart under some error conditions and once restarted, Corda will continue to operate normally.

This page lists the key changes in the 5.2 release of Corda and contains the following:

For information about upgrading a Corda cluster from 5.1 to 5.2, see Upgrading from 5.1 to 5.2.

This section describes the enhancements made in 5.2. These were made in the following areas:

The number of TPS (transactions per second) has been improved while maintaining low latency.

All database connection details must now be configured once and referenced by id during deployment. It is now possible to specify which database is used for which state type and also configure finer-grained access control.

For more information, see the PostgreSQL section of the Deployment section.

A bring-your-own-database (BYOD) feature has been introduced to enable Cluster Administrators to manage the creation and any subsequent updates of PostgreSQL databases for virtual nodes, rather than using a database managed by Corda.

For more information, see Bringing Your Own Database.

Database URLs can no longer specify the search_path parameter. If you manually create users, you must specify their search_path for their schema. For more information, see Manual Database Bootstrapping and Bringing Your Own Database.

It is now possible to integrate with Istio service mesh to secure communication between Corda workers.

For more information about configuring your deployment, see Istio Integration.

It is now possible to re-register an MGM to update the MGM’s member-provided context; for example, after a platform upgrade, after changes to the MGM’s endpoint information, or if a previous attempt by the MGM to register failed.

For more information, see Re-register an MGM.

The GET flow/{holdingIdentityShortHash} endpoint has been updated to take a flow status as an optional parameter. This enables you to filter the flows returned to those of a particular status.

For more information, see the REST API Reference.

It is now possible to change the password of RBAC users. The following new endpoints have been added:

  • /api/v5_2/user/{loginName}/selfpassword;
  • /api/v5_2/user/{loginName}/otheruserpassword.

For more information, see the REST API Reference.

It is now possible to operate a network that increases the privacy of transactions by no longer requiring every virtual node in a network to see and verify all predecessors, linked by inputs, back to issuance of a transaction on the UTXO ledger. In exchange, visibility of transaction content must be given to the notary.

For more information, see Transaction Privacy Enhancements.

Ledger repair functionality has been introduced to resolve scenarios where, due to some unexpected error, a notary notarizes a transaction but the members involved in finalizing the transaction do not store the notarized transaction. Such a scenario may result in the members repeatedly attempting to spend consumed states and their flows constantly failing with notarization failures.

The ledger repair functionality checks each member’s vault for transactions that might have been notarized, sends any such transactions to the notary to check whether they were previously seen, and updates the member’s vault if the transactions were notarized. By default, Corda runs the ledger repair process every ten minutes. This scheduled check runs for all virtual nodes in the cluster. You can also run a check manually for a particular virtual node using the new com.r3.corda.notary.plugin.common.repair.NotarizedTransactionRepairFlow flow.

For more information, see Ledger Repair.

A new setting heartbeatEnabled has been added to the corda.p2p.linkManager configuration section to specify if session heartbeat messages are enabled. Disabling heartbeats can lead to lower message overhead for a cluster, particularly for clusters that host many virtual nodes that communicate with many other virtual nodes residing in different clusters. However, it can also lead to slower failover if link manager processes become unavailable. As a result, heartbeats are enabled by default.

For more information, see corda.p2p.linkManager.

The following new settings have been added to the corda.messaging configuration section for the multi-source mediator:

  • subscription.mediator.pollTimeout
  • subscription.mediator.poolSize
  • subscription.mediator.minPoolRecordCount

The mediator is the subscription used to process flows.

For more information see corda.messaging.

A new setting lengthLimit has been added to the corda.rbac configuration section to specify the maximum number of characters of new passwords.

For more information, see corda.rbac.

It is now possible to rotate the following types of wrapping keys A key used to encrypt other keys at rest. :

  • master
  • virtual node

The following new REST API methods have been added:

For more information see, Managing Wrapping Keys.

The CorDapp template, including the runtime Gradle plugin, is now compatible with Corda 5.2. The runtime Gradle plugin wraps a subset of the SDK functions to facilitate their use in developer and CI scenarios. It replaces the CSDE Gradle plugin, which is no longer available with Corda 5.2.

For more information, see CorDapp Template.

The Contract Testing framework is now available for Corda 5.2.

For more information, see Contract Testing Framework in the Tools section.

The client can now specify a flow session-specific timeout on the Flow Message API. If the client does not provide a timeout value, Corda uses the value in the corda.flow configuration section, as in previous releases.

The web socket interface for retrieving flow status updates is no longer available.

It is now possible to register vault-named queries with an ORDER BY clause. This clause can use the database columns and the JSON representation of the states.

It is now possible to specify null parameters in vault-named queries.

The following methods have been added to UtxoLedgerService:

  • sendTransaction — sends a UtxoSignedTransaction transaction to counterparties.
  • receiveTransaction — receives a verified transaction from a counterparty session and persists it to the vault.

For more information, see the Javadocs.

The persist() API now requires a unique (within the context of a flow) deterministic deduplication ID to enable request idempotence in failure scenarios. The ID must be deterministic at the time of the function call and can not be more than 128 characters.

The tryClaim() API now requires a unique (within the context of a flow) deterministic deduplication ID to enable request idempotence in failure scenarios. The ID must be deterministic at the time of the function call and can not be more than 128 characters.

This section describes the issues resolved in 5.2. These occurred in the following areas:

Enabling sharding for the token selection worker could interfere with Ingress enabled for the REST and P2P Gateway workers. This resulted in repeated updates to the status of the Ingress resources causing a loss in connectivity to the REST API or P2P Gateway.

The crypto database cluster-level password is not re-read from Vault if it changes.

The notary virtual node selection logic (NotaryVirtualNodeSelectorServiceImpl) includes pending and suspended members.

In some instances, the flow service throws an exception if a lambda expression is used. This issue is caused by a bug in the ASM library.

Previous
Platform Support
Next
Third-Party Software Notices and Information

Was this page helpful?

Thanks for your feedback!

Chat with us

Chat with us on our #docs channel on slack. You can also join a lot of other slack channels there and have access to 1-on-1 communication with members of the R3 team and the online community.

Chat with us
Propose documentation improvements directly

Help us to improve the docs by contributing directly. It's simple - just fork this repository and raise a PR of your own - R3's Technical Writers will review it and apply the relevant suggestions.

Learn how

We're sorry this page wasn't helpful. Let us know how we can make it better!

Chat with us

Chat with us on our #docs channel on slack. You can also join a lot of other slack channels there and have access to 1-on-1 communication with members of the R3 team and the online community.

Chat with us
Create an issue

Create a new GitHub issue in this repository - submit technical feedback, draw attention to a potential documentation bug, or share ideas for improvement and general feedback.

Create a new issue
Propose documentation improvements directly

Help us to improve the docs by contributing directly. It's simple - just fork this repository and raise a PR of your own - R3's Technical Writers will review it and apply the relevant suggestions.

Learn how