Short, stable name for the condition that produced this error, e.g. "ValueNotConserved". Stable enough to assert on in a test, unlike message.
Short, stable name for the condition that produced this error, e.g. "ValueNotConserved". Stable enough to assert on in a test, unlike message.
The name is the case's own name for every case but one, whichever provider produced the error, so err.rule == "UtxoNotAvailable" means the same thing against the emulator and against a network provider. The exception is NodeSubmitError.ValidationError, the catch-all: it reports its NodeSubmitError.ValidationError.errorCode when the producer supplied one, which is how the specific condition behind an otherwise unclassified rejection reaches a caller. Those codes are producer-specific — the emulator names the ledger rule that rejected the transaction ("FeesOk", "MissingKeyHashes", … — see scalus.cardano.ledger.TransactionException.ruleName), while an HTTP provider names whatever its error body mentioned.
A ledger rule that maps onto one of the classified cases is therefore not visible here. Only rules that really are the same condition are folded together: BadInputsUTxO and BadAllInputsUTxO both report "UtxoNotAvailable", NativeScripts and PlutusScriptValidation both report "ScriptFailure", and only message says which. BadCollateralInputsUTxO and BadReferenceInputsUTxO are different conditions and reach callers under their own names. This is deliberate: the classified cases are part of the published 1.x API, and refining their rule name per instance would mean a constructor parameter and a binary break for every caller that pattern-matches them.