Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

[BUG] - cardano-submit-api cannot decode Dijkstra era transactions

Open Beginner friendly
#6,719 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 2 days

Nobody has claimed this yet.

Assessment

Difficulty
2/5
Estimated time
1-3 hours
Newbie friendliness
78/100
Issue type
Bug
Clarity
Clearly specified
Activity status
Active
Tech stack
haskell
Domain
backend

Research direction

Start in cardano-submit-api/src/Cardano/TxSubmit/Web.hs at readByteStringTx, where the issue shows the era decoder list ending at Conway. Read the cardano-cli fix linked in the issue for context, then check the submit API tests named in the report, especially the Dijkstra cases. Done means Dijkstra transactions with changed body-field encodings decode and submit rather than failing with TxCmdTxReadError.

Written by the indexing model from the issue text.

Description

bug comp: submit-api Dijkstra PV12 needs triage

Internal/External
Internal

Area
Other (cardano-submit-api)

Summary
cardano-submit-api has no Dijkstra decoder. readByteStringTx in cardano-submit-api/src/Cardano/TxSubmit/Web.hs lists the eras by hand, and the list ends at Conway:

readByteStringTx = firstExceptT TxCmdTxReadError . hoistEither . deserialiseAnyOf
  [ FromSomeType (AsTx AsShelleyEra) (InAnyShelleyBasedEra ShelleyBasedEraShelley)
  , FromSomeType (AsTx AsAllegraEra) (InAnyShelleyBasedEra ShelleyBasedEraAllegra)
  , FromSomeType (AsTx AsMaryEra)    (InAnyShelleyBasedEra ShelleyBasedEraMary)
  , FromSomeType (AsTx AsAlonzoEra)  (InAnyShelleyBasedEra ShelleyBasedEraAlonzo)
  , FromSomeType (AsTx AsBabbageEra) (InAnyShelleyBasedEra ShelleyBasedEraBabbage)
  , FromSomeType (AsTx AsConwayEra)  (InAnyShelleyBasedEra ShelleyBasedEraConway)
  ]

Simple Dijkstra transactions still go through, because the Conway decoder happens to accept them. That hides the bug. It shows up as soon as a transaction uses a body field whose encoding changed in Dijkstra. For example, required signers (body field 14) are now encoded as credentials ([0, keyhash]) where Conway expects plain key-hash bytes. Such a transaction is rejected with HTTP 400:

{"contents":{"contents":[
  "DecoderErrorDeserialiseFailure \"Shelley Tx\" (DeserialiseFailure 3 \"expected list len or indef\")",
  "DecoderErrorDeserialiseFailure \"Shelley Tx\" (DeserialiseFailure 3 \"expected list len or indef\")",
  "DecoderErrorDeserialiseFailure \"Shelley Tx\" (DeserialiseFailure 3 \"expected list len or indef\")",
  "DecoderErrorDeserialiseFailure \"Shelley Tx\" (DeserialiseFailure 3 \"expected list len or indef\")",
  "DecoderErrorDeserialiseFailure \"Shelley Tx\" (DeserialiseFailure 3 \"expected list len or indef\")",
  "DecoderErrorDeserialiseFailure \"Shelley Tx\" (DeserialiseFailure 260 \"expected bytes\")"
 ],"tag":"TxCmdTxReadError"},"tag":"TxSubmitFail"}

The same transactions submitted with cardano-cli transaction submit work: valid ones are accepted, and the negative test gets the expected ledger error instead of a decoding failure.

The code is unchanged on master (b05d8ef62), on leios-prototype, and on the 11.2 release prep branch koslambrou/prepare-11.2 (8ff994d2f). The pinned cardano-api (^>= 11.7) already provides AsDijkstraEra / ShelleyBasedEraDijkstra, so only cardano-submit-api needs to change.

Steps to reproduce

  1. Start a local testnet in the Dijkstra era (protocol version 12).
  2. Build and sign a transaction with a required signer, e.g. cardano-cli dijkstra transaction build ... --required-signer-hash <keyhash>.
  3. POST the raw CBOR to /api/submit/tx with Content-Type: application/cbor.
  4. The request fails with the TxCmdTxReadError shown above.

Found by the cardano-node-tests tests test_mint_build.py::test_witness_redeemer[*-submit_api] and test_mint_negative_build.py::test_witness_redeemer_missing_signer[submit_api-*]. All other submit_api tests pass on Dijkstra.

Expected behavior
Dijkstra transactions are decoded and submitted.

System info

  • OS Name: Fedora Linux 44
  • Node version: cardano-node 11.1.0.164 - linux-x86_64 - ghc-9.6, git rev 8bb6b68d80a8a4fb1904c48805be4f3a516593ef
  • CLI version: cardano-cli 11.2.2.0 - linux-x86_64 - ghc-9.6, git rev 8bb6b68d80a8a4fb1904c48805be4f3a516593ef
  • cardano-submit-api 11.0.0 (same build)

Additional context
cardano-cli had the same kind of hardcoded era list when reading transaction witnesses. It was fixed in IntersectMBO/cardano-cli@6605fa151 ("Derive the accepted era list when reading transaction witnesses"), which builds the list from [minBound .. maxBound]. The same approach would work here.

Dominant language
Haskell
Stars
3.2k
Forks
757
Avg merge
2d 16h
Merged PRs (30d)
17

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from IntersectMBO/cardano-node

All issues in IntersectMBO/cardano-node

Similar issues

More Haskell issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.