corda / net.corda.core.flows

Package net.corda.core.flows



Abstract flow to be used for replacing one state with another, for example when changing the notary of a state. Notably this requires a one to one replacement of states, states cannot be split, merged or issued as part of these flows.

abstract class AbstractStateReplacementFlow


Get and check the required signature.

class CollectSignatureFlow : FlowLogic<List<TransactionSignature>>


The CollectSignaturesFlow is used to automate the collection of counterparty signatures for a given transaction.

class CollectSignaturesFlow : FlowLogic<SignedTransaction>


data class ComparableRecoveryTimeWindow


A flow to be used for authorising and upgrading state objects of an old contract to a new contract.

object ContractUpgradeFlow


open class DataVendingFlow : FlowLogic<Void?>


An abstraction for flow session destinations. A flow can send to and receive from objects which implement this interface. The specifics of how the messages are routed depend on the implementation.

interface Destination


sealed class DistributionList


abstract class DistributionRecord : NamedByHash


data class DistributionRecordKey


class DistributionRecords


enum class DistributionRecordType


Verifies the given transaction, then sends it to the named notary. If the notary agrees that the transaction is acceptable then it is from that point onwards committed to the ledger, and will be written through to the vault. Additionally, it will be distributed to the parties reflected in the participants list of the states.

class FinalityFlow : FlowLogic<SignedTransaction>


TWO_PHASE_FINALITY Recovery Flow This flow is exposed via the Core API for use by any CorDapp but its implementation is available in Enterprise only.

class FinalityRecoveryFlow : FlowLogic<Map<FlowTransactionInfo, Boolean>>


FlowExternalAsyncOperation represents an external future that blocks a flow from continuing until the future returned by FlowExternalAsyncOperation.execute has completed. Examples of external processes where FlowExternalAsyncOperation would be useful include, triggering a long running process on an external system or retrieving information from a service that might be down.

interface FlowExternalAsyncOperation<R : Any>


FlowExternalOperation represents an external process that blocks a flow from continuing until the result of execute has been retrieved. Examples of external processes where FlowExternalOperation would be useful include, triggering a long running process on an external system or retrieving information from a service that might be down.

interface FlowExternalOperation<R : Any>


Version and name of the CorDapp hosting the other side of the flow.

data class FlowInfo


Please note that FlowInitiator has been superceded by net.corda.core.context.InvocationContext, which offers more detail for the same event.

sealed class FlowInitiator : Principal


A sub-class of FlowLogic implements a flow using direct, straight line blocking code. Thus you can write complex flow logic in an ordinary fashion, without having to think about callbacks, restarting after a node crash, how many instances of your flow there are running and so on.

abstract class FlowLogic<out T>


A handle interface representing a FlowLogic instance which would be possible to safely pass out of the contract sandbox. Use FlowLogicRefFactory to construct a concrete security checked instance.

interface FlowLogicRef


The public factory interface for creating validated FlowLogicRef instances as part of the scheduling framework.

interface FlowLogicRefFactory


data class FlowRecoveryQuery


A FlowSession is a handle on a communication sequence between two paired flows, possibly running on separate nodes. It is used to send and receive messages between the flows as well as to query information about the counter-flow.

abstract class FlowSession


Main data object representing snapshot of the flow stack, extracted from the Quasar stack.

data class FlowStackSnapshot


data class FlowTimeWindow


Transaction recovery type information.

data class FlowTransactionInfo


Ledger Recovery Flow (available in Enterprise only).

class LedgerRecoveryFlow : FlowLogic<LedgerRecoveryResult>


data class LedgerRecoveryParameters


data class LedgerRecoveryResult


In the words of Matt working code is more important then pretty code. This class that contains code that may be serialized. If it were always serialized then the local disk fetch would need to serialize then de-serialize which wastes time. However over the wire we get batch fetch items serialized. This is because we need to get the exact length of the objects to pack them into the 10MB max message size buffer. We do not want to serialize them multiple times so it's a lot more efficient to send the byte stream.

class MaybeSerializedSignedTransaction : NamedByHash


Container for the transaction and notarisation request signature. This is the payload that gets sent by a client to a notary service for committing the input states of the transaction.

data class NotarisationPayload


A notarisation request specifies a list of states to consume and the id of the consuming transaction. Its primary purpose is for notarisation traceability – a signature over the notarisation request, NotarisationRequestSignature, allows a notary to prove that a certain party requested the consumption of a particular state.

class NotarisationRequest


A wrapper around a digital signature used for notarisation requests.

data class NotarisationRequestSignature


Payload returned by the notary service flow to the client.

data class NotarisationResponse


A flow to be used for changing a state's Notary. This is required since all input states to a transaction must point to the same notary.

class NotaryChangeFlow<out T : ContractState> : Instigator<T, T, Party>


Specifies the cause for notarisation request failure.

sealed class NotaryError


class NotaryFlow


object NotarySigCheck


The receiving counterpart to FinalityFlow.

class ReceiveFinalityFlow : FlowLogic<SignedTransaction>


data class ReceiverDistributionRecord : DistributionRecord


The ReceiveStateAndRefFlow should be called in response to the SendStateAndRefFlow.

class ReceiveStateAndRefFlow<out T : ContractState> : FlowLogic<List<StateAndRef<T>>>


The ReceiveTransactionFlow should be called in response to the SendTransactionFlow.

open class ReceiveTransactionFlow : FlowLogic<SignedTransaction>


data class RecoveryTimeWindow


data class SenderDistributionRecord : DistributionRecord


The SendStateAndRefFlow should be used to send a list of input StateAndRef to another peer that wishes to verify the input's integrity by resolving and checking the dependencies as well. The other side should invoke ReceiveStateAndRefFlow at the right point in the conversation to receive the input state and ref and perform the resolution back-and-forth required to check the dependencies.

open class SendStateAndRefFlow : DataVendingFlow


The SendTransactionFlow should be used to send a transaction to another peer that wishes to verify that transaction's integrity by resolving and checking the dependencies as well. The other side should invoke ReceiveTransactionFlow at the right point in the conversation to receive the sent transaction and perform the resolution back-and-forth required to check the dependencies and download any missing attachments.

open class SendTransactionFlow : DataVendingFlow


data class SignedTransactionWithDistributionList


The SignTransactionFlow should be called in response to the CollectSignaturesFlow. It automates the signing of a transaction providing the transaction:

abstract class SignTransactionFlow : FlowLogic<SignedTransaction>


Token class, used to indicate stack presence of the corda internal data. Since this data is of no use for a CordApp developer, it is skipped from serialisation and its presence is only marked by this token.

data class StackFrameDataToken


Contains information about the consuming transaction for a particular state.

data class StateConsumptionDetails


A unique identifier for a single state machine run, valid across node restarts. Note that a single run always has at least one flow, but that flow may also invoke sub-flows: they all share the same run id.

data class StateMachineRunId


data class TransactionMetadata


Sent by the notary when the notary detects it will unlikely respond before the client retries.

data class WaitTimeUpdate


Given a flow which uses reference states, the WithReferencedStatesFlow will execute the flow as a subFlow. If the flow fails due to a NotaryError.Conflict for a reference state, then WithReferencedStatesFlow will be suspended until the state refs for the reference states are consumed. In this case, a consumption means that:

class WithReferencedStatesFlow<T : Any> : FlowLogic<T>



This annotation is required by any FlowLogic that is designed to be initiated by a counterparty flow. The class must have at least a constructor which takes in a single net.corda.core.identity.Party parameter which represents the initiating counterparty. The FlowLogic that does the initiating is specified by the value property and itself must be annotated with InitiatingFlow.

annotation class InitiatedBy


This annotation is required by any FlowLogic which has been designated to initiate communication with a counterparty and request they start their side of the flow communication.

annotation class InitiatingFlow


Any FlowLogic which is schedulable and is designed to be invoked by a net.corda.core.contracts.SchedulableState must have this annotation. If it's missing FlowLogicRefFactory.create will throw an exception when it comes time to schedule the next activity in net.corda.core.contracts.SchedulableState.nextScheduledActivity.

annotation class SchedulableFlow


Any FlowLogic which is to be started by the RPC interface (net.corda.core.messaging.CordaRPCOps.startFlowDynamic and net.corda.core.messaging.CordaRPCOps.startTrackedFlowDynamic) must have this annotation. If it's missing the flow will not be allowed to start and an exception will be thrown.

annotation class StartableByRPC


Any FlowLogic which is to be started by the AppServiceHub interface from within a CordaService must have this annotation. If it's missing the flow will not be allowed to start and an exception will be thrown.

annotation class StartableByService



Exception which can be thrown by a FlowLogic at any point in its logic to unexpectedly bring it to a permanent end. The exception will propagate to all counterparty flows and will be thrown on their end the next time they wait on a FlowSession.receive or FlowSession.sendAndReceive. Any flow which no longer needs to do a receive, or has already ended, will not receive the exception (if this is required then have them wait for a confirmation message).

open class FlowException : CordaException, IdentifiableException


class FlowRecoveryException : FlowException


This exception allows a flow to pass itself to the flow hospital. Once the flow reaches the hospital it will determine how to progress depending on what causes the exception wraps. Assuming there are no important wrapped exceptions, throwing a HospitalizeFlowException will place the flow in overnight observation, where it will be replayed at a later time.

open class HospitalizeFlowException : CordaRuntimeException


Thrown if the structure of a class implementing a flow is not correct. There can be several causes for this such as not inheriting from FlowLogic, not having a valid constructor and so on.

class IllegalFlowLogicException : IllegalArgumentException


An exception that is thrown when a flow has been killed.

class KilledFlowException : CordaRuntimeException


class LedgerRecoveryException : FlowException


Exception thrown by the notary service if any issues are encountered while trying to commit a transaction. The underlying error specifies the cause of failure.

class NotaryException : FlowException


Thrown whenever a flow result cannot be serialized when attempting to save it in the database

class ResultSerializationException : CordaRuntimeException


open class StateReplacementException : FlowException


Thrown when a flow session ends unexpectedly due to a type mismatch (the other side sent an object of a type that we were not expecting), or the other side had an internal error, or the other side terminated when we were waiting for a response.

class UnexpectedFlowEndException : CordaRuntimeException, IdentifiableException