docs/net.corda.core.contracts/TransactionVerificationException/ConflictingAttachmentsRejection

ConflictingAttachmentsRejection

class ConflictingAttachmentsRejection(val txId: SecureHash, val contractClass: String) : 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.

Constructors

constructor(txId: SecureHash, contractClass: String)

Properties

cause

open override val cause: Throwable?

contractClass

val contractClass: String

The fully qualified class name of the failing contract.

message

open override val message: String?

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.