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.
Direction |
Whether the inputs or outputs list contains an encumbrance issue, see TransactionMissingEncumbranceException. enum class Direction |
AttachmentTooBigException |
class AttachmentTooBigException : TransactionVerificationException |
BrokenTransactionException |
class BrokenTransactionException : TransactionVerificationException |
ConflictingAttachmentsRejection |
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. class ConflictingAttachmentsRejection : TransactionVerificationException |
ConstraintPropagationRejection |
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. class ConstraintPropagationRejection : TransactionVerificationException |
ContractConstraintRejection |
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. class ContractConstraintRejection : TransactionVerificationException |
ContractCreationError |
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. class ContractCreationError : TransactionVerificationException |
ContractRejection |
Indicates that one of the Contract.verify methods selected by the contract constraints and attachments rejected the transaction by throwing an exception. class ContractRejection : TransactionVerificationException |
DuplicateAttachmentsRejection |
Indicates that the same attachment has been added multiple times to a transaction. class DuplicateAttachmentsRejection : TransactionVerificationException |
InvalidAttachmentException |
class InvalidAttachmentException : TransactionVerificationException |
InvalidConstraintRejection |
A constraint attached to a state was invalid, e.g. due to size limitations. class InvalidConstraintRejection : TransactionVerificationException |
MissingAttachmentRejection |
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. class MissingAttachmentRejection : TransactionVerificationException |
MissingNetworkParametersException |
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. class MissingNetworkParametersException : TransactionVerificationException |
NotaryChangeInWrongTransactionType |
An output state has a notary that doesn't match the transaction's notary field. It must! class NotaryChangeInWrongTransactionType : TransactionVerificationException |
OverlappingAttachmentsException |
Thrown when multiple attachments provide the same file when building the AttachmentsClassloader for a transaction. class OverlappingAttachmentsException : TransactionVerificationException |
PackageOwnershipException |
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. class PackageOwnershipException : TransactionVerificationException |
TransactionContractConflictException |
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. class TransactionContractConflictException : TransactionVerificationException |
TransactionDuplicateEncumbranceException |
If two or more states refer to another state (as their encumbrance), then the bi-directionality property cannot be satisfied. class TransactionDuplicateEncumbranceException : TransactionVerificationException |
TransactionMissingEncumbranceException |
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. class TransactionMissingEncumbranceException : TransactionVerificationException |
TransactionNetworkParameterOrderingException |
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. class TransactionNetworkParameterOrderingException : TransactionVerificationException |
TransactionNonMatchingEncumbranceException |
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). class TransactionNonMatchingEncumbranceException : TransactionVerificationException |
TransactionNotaryMismatchEncumbranceException |
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. class TransactionNotaryMismatchEncumbranceException : TransactionVerificationException |
TransactionRequiredContractUnspecifiedException |
class TransactionRequiredContractUnspecifiedException : TransactionVerificationException |
UnsupportedClassVersionError |
class UnsupportedClassVersionError : TransactionVerificationException |
UnsupportedHashTypeException |
class UnsupportedHashTypeException : TransactionVerificationException |
UntrustedAttachmentsException |
Thrown during classloading upon encountering an untrusted attachment (eg. not in the TRUSTED_UPLOADERS list) class UntrustedAttachmentsException : CordaException |
<init> |
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. TransactionVerificationException(txId: SecureHash, message: String, cause: Throwable?) |
txId |
the Merkle root hash (identifier) of the transaction that failed verification. val txId: SecureHash |