DeserialiseFailure on resubmitting Conway Tx with invalid plutus script

[mkoura]

I'm getting following DeserialiseFailure when trying to resubmit a Tx with invalid Plutus script in Conway era:

cardano-cli: DecoderFailure (LocalTxSubmission (GenTx (HardForkBlock (': ByronBlock (': (ShelleyBlock (TPraos StandardCrypto) (ShelleyEra StandardCrypto)) (': (ShelleyBlock (TPraos StandardCrypto) (AllegraEra StandardCrypto)) (': (ShelleyBlock (TPraos StandardCrypto) (MaryEra StandardCrypto)) (': (ShelleyBlock (TPraos StandardCrypto) (AlonzoEra StandardCrypto)) (': (ShelleyBlock (Praos StandardCrypto) (BabbageEra StandardCrypto)) (': (ShelleyBlock (Praos StandardCrypto) (ConwayEra StandardCrypto)) ('[] )))))))))) (HardForkApplyTxErr (': ByronBlock (': (ShelleyBlock (TPraos StandardCrypto) (ShelleyEra StandardCrypto)) (': (ShelleyBlock (TPraos StandardCrypto) (AllegraEra StandardCrypto)) (': (ShelleyBlock (TPraos StandardCrypto) (MaryEra StandardCrypto)) (': (ShelleyBlock (TPraos StandardCrypto) (AlonzoEra StandardCrypto)) (': (ShelleyBlock (Praos StandardCrypto) (BabbageEra StandardCrypto)) (': (ShelleyBlock (Praos StandardCrypto) (ConwayEra StandardCrypto)) ('[] )))))))))) ServerAgency TokBusy) (DeserialiseFailure 68 "expected word")

I'm testing this with cardano-node / cardano-cli 8.9.0 release.

UPDATE: It is somehow related to return collateral. If collateral utxos have the precise collateral amount, then no return collateral txout is needed. In such case, resubmitting the tx leads to the expected BadInputsUTxO, instead of the unexpected DecoderFailure.

Steps to reproduce:

1. build

   cardano-cli conway transaction build --tx-in "745f04573e7429be1404f9b936d208b81159f3fc4b30037b9d630187eec18756#0" --tx-in-script-file cardano_node_tests/tests/data/plutus/v1/always-fails.plutus --tx-in-datum-file cardano_node_tests/tests/data/plutus/typed-42.datum --tx-in-redeemer-file cardano_node_tests/tests/data/plutus/typed-42.redeemer --tx-in-collateral "745f04573e7429be1404f9b936d208b81159f3fc4b30037b9d630187eec18756#1" --tx-in "745f04573e7429be1404f9b936d208b81159f3fc4b30037b9d630187eec18756#2" --tx-out "addr_test1vr7l4ff9r60dyxr22thw5pdvr5ucxnhw7zdnuswuz52h0gqy8q9yn+2000000" --script-invalid --change-address addr_test1vrlfyrycpk7pzyaqrkcp2624g70nhy0kld49r0wqcwpurwgcmxy52 --out-file test_script_invalid_ci0_hmg_step2_tx.body --testnet-magic 42

2. sign

   cardano-cli conway transaction sign --tx-body-file test_script_invalid_ci0_hmg_step2_tx.body --testnet-magic 42 --signing-key-file test_script_invalid_ci0_glp_payment_addr_0.skey --signing-key-file test_script_invalid_ci0_glp_payment_addr_1.skey --out-file test_script_invalid_ci0_hmg_step2_tx.signed

3. submit

   cardano-cli conway transaction submit --testnet-magic 42 --tx-file test_script_invalid_ci0_hmg_step2_tx.signed --cardano-mode

4. resubmit to see if the tx made it to mempool. Expected behavior is to get BadInputsUTxO, but this time we get the DecoderFailure.

Files used in the test: deserialize_failure.tar.gz

[Soupstraw]

I tried to reproduce the decoder failure with the files you provided, but it seems to decode the transaction just fine with cardano-ledger-conway-1.12.0.0. Could this be a decoder failure from another component?

LocalTxSubmission is not from the ledger codebase, maybe it does something to make the decoder fail?

[mkoura]

It is strange that the error happens only on tx resubmit. So it must be decoded ok during first submission. Could it be consensus issue?

[Soupstraw]

Yeah, I think it makes sense to report it to consensus and see if they can track it to ledger or if its something on their side.

[lehins]

Nice catch. This is a bug in deserialization of a predicate failure, not of a transaction.