Skip to content

Add cardano-node 11.0.1 support#204

Draft
johnalotoski wants to merge 11 commits into
CardanoSolutions:masterfrom
johnalotoski:feature/node-11.0
Draft

Add cardano-node 11.0.1 support#204
johnalotoski wants to merge 11 commits into
CardanoSolutions:masterfrom
johnalotoski:feature/node-11.0

Conversation

@johnalotoski
Copy link
Copy Markdown

Add support for cardano-node 11.0.1 and the Dijkstra era (protocol version 12).

The changes in this PR were generated by Claude and are being reviewed by @erikd.

Dependencies

  • Bump cabal.project constraints: cardano-node == 11.0.1, ouroboros-consensus ^>= 3.0.1, cardano-ledger-conway >= 1.22.1
  • Update hackage and CHaP index-state to 2026-05-08
  • Pin validation < 1.2 to avoid breaking API change in validation-1.2
  • Update ogmios source-repository-package to rebased node-11.0 branch

Dijkstra era support

  • Add BlockDijkstra / DijkstraEra pattern matches across block processing, scripts, transactions, and Hydra/Ogmios modules
  • Dijkstra transactions are coerced to TransactionConway at the block-processing boundary since the types are representationally identical (documented with comment)
  • Replace unsafeCoerce in Metadata era translation (fromAlonzoMetadata, fromBabbageMetadata) with explicit pattern match and translateTimelock
  • Update Prelude era list and codec config

Notes

  • Metadata type alias kept as AlonzoTxAuxData ConwayEra rather than DijkstraEra since Dijkstra transactions are already handled as Conway at the processing boundary (documented with comment)
  • One unsafeCoerce remains in Cardano.hs for Tx TopTx DijkstraEra → Tx TopTx ConwayEra coercion — the nominal type role prevents coerce, and adding a TransactionDijkstra constructor would duplicate all Conway handling

Test plan

  • cabal build exe:kupo succeeds

Comment thread cabal.project Outdated
tag: ae876badb138f42dcd6d2389734b0c15502684ed
--sha256: xkOfOdX6Dxi7+VW78Tk3n3MoguIg39pKdxiNVfdeEwE=
location: https://github.com/johnalotoski/ogmios
tag: 994d39d38e3fa244e8ba8687fa9fd4d1e7101261
Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

To be updated once CardanoSolutions/ogmios#461 merges

@notunrandom notunrandom self-assigned this May 13, 2026
@notunrandom
Copy link
Copy Markdown
Collaborator

notunrandom commented May 13, 2026

Thank you @johnalotoski for this contribution.
I was able to reproduce your successful build.
Moreover, only one out of 335 unit tests failed.
My next steps:

  • look into the failing unit test
  • try it out with a preview node
  • try it out with a preprod node
  • run end-to-end tests on the preprod node

We look forward to hearing from the review by @erikd.
Hopefully @KtorZ can also have a look.

@johnalotoski johnalotoski force-pushed the feature/node-11.0 branch 2 times, most recently from 98d3c55 to 53ea43a Compare May 14, 2026 04:33
johnalotoski and others added 10 commits May 13, 2026 23:59
Update cabal.project constraints and index-state for cardano-node
11.0.1 (ouroboros-consensus 3.0.1, cardano-ledger-conway >= 1.22.1).
Pin validation < 1.2 to avoid breaking API change. Update ogmios
source-repository-package to rebased node-11.0 branch. Bump
dependency bounds in package.yaml.

Co-Authored-By: Claude <noreply@anthropic.com>
Add BlockDijkstra and DijkstraEra pattern matches across block
processing, scripts, transactions, and Hydra/Ogmios modules. Dijkstra
transactions are coerced to Conway at the block-processing boundary
since the types are representationally identical. Replace unsafeCoerce
in Metadata era translation with explicit pattern match and
translateTimelock. Update Prelude era list and codec config.

Co-Authored-By: Claude <noreply@anthropic.com>
…wayEra

Replace the unsafeCoerce-based approach to Dijkstra era handling with
proper TransactionDijkstra constructors and explicit era conversion
functions. Change the Metadata, Output, Script, and BinaryData type
aliases from ConwayEra to DijkstraEra and add the necessary upgrade
paths through all era conversion functions using Ledger.Dijkstra.upgradeTimelock.

Add cardano-ledger-dijkstra as an explicit dependency.

Co-Authored-By: Claude <noreply@anthropic.com>
Replace unsafeBinaryDataFromBytes with Ledger.dataToBinaryData and
Ledger.upgradeData for era conversions. With BinaryData now aliased
to DijkstraEra, fromDijkstraBinaryData and toDijkstraBinaryData
simplify to identity. Uses coerce for the phantom era parameter in
Conway datum conversions.

Co-Authored-By: Claude <noreply@anthropic.com>
Replace Timelock ConwayEra with DijkstraNativeScript DijkstraEra and
simplify scriptFromBytes to decode directly at DijkstraEra instead of
decoding at ConwayEra and upgrading. Removes the extra upgradeTimelock
and fromConwayScript steps from fromNativeScript.

Co-Authored-By: Claude <noreply@anthropic.com>
Add comment noting that ouroboros-network provides a general
ToJSON (Point block) instance that conflicts with this one.

Co-Authored-By: Claude <noreply@anthropic.com>
Use Ledger.dataToBinaryData with Ledger.upgradeData for Alonzo and
Babbage era data conversions, removing the HasCallStack constraint
from fromAlonzoData and the intermediate type annotation from
fromBabbageData.

Co-Authored-By: Claude <noreply@anthropic.com>
These Conway-era datum conversions are dead code now that the Datum,
BinaryData, and Output types are all aliased to DijkstraEra.

Co-Authored-By: Claude <noreply@anthropic.com>
The previous genServerPort (1024 + size + arbitrary) could generate
privileged ports below 1024 and duplicate ports across iterations,
causing bind failures. Replace with OS-assigned ephemeral ports via
bind-to-zero on localhost. Also use newEnvironmentWith throwIO so
test failures surface the real exception instead of opaque ExitFailure 1.

Co-Authored-By: Claude <noreply@anthropic.com>
Co-Authored-By: Claude <noreply@anthropic.com>
@erikd
Copy link
Copy Markdown

erikd commented May 23, 2026

@notunrandom I have reviewed this directly with @johnalotoski and he has incorporated my suggestions.

Copy link
Copy Markdown
Member

@KtorZ KtorZ left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks reasonable; I am just wondering about the consequence of enabling/defaulting to Dijkstra already when the era isn't yet finished nor available.

It might be safer and less headache to keep Conway in places where we can.


type BinaryData =
Ledger.BinaryData ConwayEra
Ledger.BinaryData DijkstraEra
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think we want that now; unless there's no breaking changes there.

  This is only used to pull in the fast-bech32 module, which is not impacted by the hard fork at all.
@notunrandom
Copy link
Copy Markdown
Collaborator

Current testing status:

  • build OK
  • unit tests OK
  • end-to-end tests (on preprod) mostly OK, only 4 are failing and it seems to be a problem with the way the tests are run, not an actual problem with the code.
  • manually running this version of Kupo against a cardano-node 11.0.1 on preview works without any visible problems, I've tried various --since values and various --match values and several queries (health, checkpoints, match, match with ?unspent).

@KtorZ is there anything else you want me to test before we merge? And what do you want to do about your last comment? (#204 (comment))

@KtorZ
Copy link
Copy Markdown
Member

KtorZ commented May 28, 2026

@notunrandom You did not manage to get to the bottom of this handle closing itself in the end?

@notunrandom
Copy link
Copy Markdown
Collaborator

@notunrandom You did not manage to get to the bottom of this handle closing itself in the end?

Not yet. I believe it's correct for the handle to be closed, but not correct for something to write to it after (because by the time the error happens the next temporary trace file has already been created). I think there is something going on with either the threads of the tests, or the lazy writing to the handle, or both. I'm still trying to make sense of the code that runs those tests. I'll keep digging.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants