corda / net.corda.core.contracts / TransactionVerificationException

TransactionVerificationException

abstract class TransactionVerificationException : FlowException

Indicates that some aspect of the transaction named by txId violates the platform rules. The exact type of failure is expressed using a subclass. TransactionVerificationException is a FlowException and thus when thrown inside a flow, the details of the failure will be serialised, propagated to the peer and rethrown.

Types

Direction

enum class Direction

Whether the inputs or outputs list contains an encumbrance issue, see TransactionMissingEncumbranceException.

Exceptions

ConflictingAttachmentsRejection

class ConflictingAttachmentsRejection : TransactionVerificationException

Indicates this transaction violates the "no overlap" rule: two attachments are trying to provide the same file path. Whereas Java classpaths would normally allow that with the first class taking precedence, this is not allowed in transactions for security reasons. This usually indicates that two separate apps share a dependency, in which case you could try 'shading the fat jars' to rename classes of dependencies. Or you could manually attach dependency JARs when building the transaction.

ConstraintPropagationRejection

class ConstraintPropagationRejection : TransactionVerificationException

This exception happens when a transaction was not built correctly. When a contract is not annotated with NoConstraintPropagation, then the platform ensures that the constraints of output states transition correctly from input states.

ContractConstraintRejection

class ContractConstraintRejection : TransactionVerificationException

The transaction attachment that contains the contractClass class didn't meet the constraints specified by the TransactionState.constraint object. This usually implies a version mismatch of some kind.

ContractCreationError

class ContractCreationError : TransactionVerificationException

A Contract class named by a state could not be constructed. Most likely you do not have a no-argument constructor, or the class doesn't subclass Contract.

ContractRejection

class ContractRejection : TransactionVerificationException

Indicates that one of the Contract.verify methods selected by the contract constraints and attachments rejected the transaction by throwing an exception.

DuplicateAttachmentsRejection

class DuplicateAttachmentsRejection : TransactionVerificationException

Indicates that the same attachment has been added multiple times to a transaction.

InvalidAttachmentException

class InvalidAttachmentException : TransactionVerificationException

MissingAttachmentRejection

class MissingAttachmentRejection : TransactionVerificationException

A state requested a contract class via its TransactionState.contract field that didn't appear in any attached JAR at all. This usually implies the attachments were forgotten or a version mismatch.

MissingNetworkParametersException

class MissingNetworkParametersException : TransactionVerificationException

Thrown when the network parameters with hash: missingNetworkParametersHash is not available at this node. Usually all the parameters that are in the resolution chain for transaction with txId should be fetched from peer via FetchParametersFlow or from network map.

NotaryChangeInWrongTransactionType

class NotaryChangeInWrongTransactionType : TransactionVerificationException

An output state has a notary that doesn't match the transaction's notary field. It must!

OverlappingAttachmentsException

class OverlappingAttachmentsException : TransactionVerificationException

Thrown when multiple attachments provide the same file when building the AttachmentsClassloader for a transaction.

PackageOwnershipException

class PackageOwnershipException : TransactionVerificationException

Thrown to indicate that a contract attachment is not signed by the network-wide package owner. Please note that the txId will always be SecureHash.zeroHash because package ownership is an error with a particular attachment, and because attachment classloaders are reused this is independent of any particular transaction.

TransactionContractConflictException

class TransactionContractConflictException : TransactionVerificationException

If a state is identified as belonging to a contract, either because the state class is defined as an inner class of the contract class or because the state class is annotated with BelongsToContract, then it must not be bundled in a TransactionState with a different contract.

TransactionDuplicateEncumbranceException

class TransactionDuplicateEncumbranceException : TransactionVerificationException

If two or more states refer to another state (as their encumbrance), then the bi-directionality property cannot be satisfied.

TransactionMissingEncumbranceException

class TransactionMissingEncumbranceException : TransactionVerificationException

If a state is encumbered (the TransactionState.encumbrance field is set) then its encumbrance must be used as an input to any transaction that uses it. In this way states can be tied together in chains, thus composing logic. Note that encumbrances aren't fully supported by all aspects of the platform at this time so if you use them, you may find transactions created by the platform don't always respect the encumbrance rule.

TransactionNetworkParameterOrderingException

class TransactionNetworkParameterOrderingException : TransactionVerificationException

If the network parameters associated with an input or reference state in a transaction are more recent than the network parameters of the new transaction itself.

TransactionNonMatchingEncumbranceException

class TransactionNonMatchingEncumbranceException : TransactionVerificationException

An encumbered state should also be referenced as the encumbrance of another state in order to satisfy the bi-directionality property (a full cycle should be present).

TransactionNotaryMismatchEncumbranceException

class TransactionNotaryMismatchEncumbranceException : TransactionVerificationException

All encumbered states should be assigned to the same notary. This is due to the fact that multi-notary transactions are not supported and thus two encumbered states with different notaries cannot be consumed in the same transaction.

TransactionRequiredContractUnspecifiedException

class TransactionRequiredContractUnspecifiedException : TransactionVerificationException

UntrustedAttachmentsException

class UntrustedAttachmentsException : CordaException

Thrown during classloading upon encountering an untrusted attachment (eg. not in the TRUSTED_UPLOADERS list)

Constructors

<init>

TransactionVerificationException(txId: SecureHash, message: String, cause: Throwable?)

Indicates that some aspect of the transaction named by txId violates the platform rules. The exact type of failure is expressed using a subclass. TransactionVerificationException is a FlowException and thus when thrown inside a flow, the details of the failure will be serialised, propagated to the peer and rethrown.

Properties

txId

val txId: SecureHash

the Merkle root hash (identifier) of the transaction that failed verification.

Inherited Properties

originalErrorId

var originalErrorId: Long?

the ID backing getErrorId. If null it will be set dynamically by the flow framework when the exception is handled. This ID is propagated to counterparty flows, even when the FlowException is downgraded to an UnexpectedFlowEndException. This is so the error conditions may be correlated later on.

Inherited Functions

getErrorId

open fun getErrorId(): Long?

Extension Functions

contextLogger

fun Any.contextLogger(): Logger

When called from a companion object, returns the logger for the enclosing class.

Inheritors

ConflictingAttachmentsRejection

class ConflictingAttachmentsRejection : TransactionVerificationException

Indicates this transaction violates the "no overlap" rule: two attachments are trying to provide the same file path. Whereas Java classpaths would normally allow that with the first class taking precedence, this is not allowed in transactions for security reasons. This usually indicates that two separate apps share a dependency, in which case you could try 'shading the fat jars' to rename classes of dependencies. Or you could manually attach dependency JARs when building the transaction.

ConstraintPropagationRejection

class ConstraintPropagationRejection : TransactionVerificationException

This exception happens when a transaction was not built correctly. When a contract is not annotated with NoConstraintPropagation, then the platform ensures that the constraints of output states transition correctly from input states.

ContractConstraintRejection

class ContractConstraintRejection : TransactionVerificationException

The transaction attachment that contains the contractClass class didn't meet the constraints specified by the TransactionState.constraint object. This usually implies a version mismatch of some kind.

ContractCreationError

class ContractCreationError : TransactionVerificationException

A Contract class named by a state could not be constructed. Most likely you do not have a no-argument constructor, or the class doesn't subclass Contract.

ContractRejection

class ContractRejection : TransactionVerificationException

Indicates that one of the Contract.verify methods selected by the contract constraints and attachments rejected the transaction by throwing an exception.

DuplicateAttachmentsRejection

class DuplicateAttachmentsRejection : TransactionVerificationException

Indicates that the same attachment has been added multiple times to a transaction.

InvalidAttachmentException

class InvalidAttachmentException : TransactionVerificationException

MissingAttachmentRejection

class MissingAttachmentRejection : TransactionVerificationException

A state requested a contract class via its TransactionState.contract field that didn't appear in any attached JAR at all. This usually implies the attachments were forgotten or a version mismatch.

MissingNetworkParametersException

class MissingNetworkParametersException : TransactionVerificationException

Thrown when the network parameters with hash: missingNetworkParametersHash is not available at this node. Usually all the parameters that are in the resolution chain for transaction with txId should be fetched from peer via FetchParametersFlow or from network map.

NotaryChangeInWrongTransactionType

class NotaryChangeInWrongTransactionType : TransactionVerificationException

An output state has a notary that doesn't match the transaction's notary field. It must!

OverlappingAttachmentsException

class OverlappingAttachmentsException : TransactionVerificationException

Thrown when multiple attachments provide the same file when building the AttachmentsClassloader for a transaction.

PackageOwnershipException

class PackageOwnershipException : TransactionVerificationException

Thrown to indicate that a contract attachment is not signed by the network-wide package owner. Please note that the txId will always be SecureHash.zeroHash because package ownership is an error with a particular attachment, and because attachment classloaders are reused this is independent of any particular transaction.

TransactionContractConflictException

class TransactionContractConflictException : TransactionVerificationException

If a state is identified as belonging to a contract, either because the state class is defined as an inner class of the contract class or because the state class is annotated with BelongsToContract, then it must not be bundled in a TransactionState with a different contract.

TransactionDuplicateEncumbranceException

class TransactionDuplicateEncumbranceException : TransactionVerificationException

If two or more states refer to another state (as their encumbrance), then the bi-directionality property cannot be satisfied.

TransactionMissingEncumbranceException

class TransactionMissingEncumbranceException : TransactionVerificationException

If a state is encumbered (the TransactionState.encumbrance field is set) then its encumbrance must be used as an input to any transaction that uses it. In this way states can be tied together in chains, thus composing logic. Note that encumbrances aren't fully supported by all aspects of the platform at this time so if you use them, you may find transactions created by the platform don't always respect the encumbrance rule.

TransactionNetworkParameterOrderingException

class TransactionNetworkParameterOrderingException : TransactionVerificationException

If the network parameters associated with an input or reference state in a transaction are more recent than the network parameters of the new transaction itself.

TransactionNonMatchingEncumbranceException

class TransactionNonMatchingEncumbranceException : TransactionVerificationException

An encumbered state should also be referenced as the encumbrance of another state in order to satisfy the bi-directionality property (a full cycle should be present).

TransactionNotaryMismatchEncumbranceException

class TransactionNotaryMismatchEncumbranceException : TransactionVerificationException

All encumbered states should be assigned to the same notary. This is due to the fact that multi-notary transactions are not supported and thus two encumbered states with different notaries cannot be consumed in the same transaction.

TransactionRequiredContractUnspecifiedException

class TransactionRequiredContractUnspecifiedException : TransactionVerificationException