search

IntersectMBO / cardano-cli

This repository contains sources for the command-line interface (CLI) tool for interacting with the Cardano blockchain.
Apache License 2.0
39 stars 15 forks source link

`babbage transaction view` on Babbage-era transaction shows some Conway era fields #799

Closed mkoura closed 2 months ago

mkoura commented 3 months ago

Description

The transaction view in Babbage era for Babbage Tx shows "governance actions" and "voters". These are applicable only to Conway era transactions.

Steps to Reproduce

  1. cardano-cli babbage transaction view --tx-file babbage_era.tx

Additional Context

cardano-cli 8.24.0.0 - linux-x86_64 - ghc-8.10
git rev ae8bc933ee6b6366c04854c1e127fd8dfb29b556

cardano-node 8.12.0 - linux-x86_64 - ghc-8.10
git rev ae8bc933ee6b6366c04854c1e127fd8dfb29b556

Work on-going at https://github.com/IntersectMBO/cardano-cli/commits/smelc/more-era-dependent-in-transaction-view/

smelc commented 3 months ago

@Jimbo4350> I need your wisdom here.

In transaction view, the era passed on the command line is ignored:

  1. The commmand's datatype doesn't keep track of the era specified on the command line: https://github.com/IntersectMBO/cardano-cli/blob/0e085e6ebd5ede10e9c84c1cb106bd9639aab3e8/cardano-cli/src/Cardano/CLI/EraBased/Commands/Transaction.hs#L234
  2. The era is chosen when reading the transaction from disk: https://github.com/IntersectMBO/cardano-cli/blob/0e085e6ebd5ede10e9c84c1cb106bd9639aab3e8/cardano-cli/src/Cardano/CLI/EraBased/Run/Transaction.hs#L1437

With my example transaction, reading from disk returns the babbage era, which means that, if we condition the behavior of transaction view on the era; the output will be tailored for babbage (for example ignoring the voters field). Which is weird if the user called cardano-cli conway transaction.

How should I settle this conflict between the era specified by the user and the one inferred from the file on disk?

cc @CarlosLopezDeLara , because this explains the surprising behavior we were observing last Friday.

Jimbo4350 commented 3 months ago

@Jimbo4350> I need your wisdom here.

In transaction view, the era passed on the command line is ignored:

1. The commmand's datatype doesn't keep track of the era specified on the command line: https://github.com/IntersectMBO/cardano-cli/blob/0e085e6ebd5ede10e9c84c1cb106bd9639aab3e8/cardano-cli/src/Cardano/CLI/EraBased/Commands/Transaction.hs#L234

2. The `era` is chosen when reading the transaction from disk: https://github.com/IntersectMBO/cardano-cli/blob/0e085e6ebd5ede10e9c84c1cb106bd9639aab3e8/cardano-cli/src/Cardano/CLI/EraBased/Run/Transaction.hs#L1437

With my example transaction, reading from disk returns the babbage era, which means that, if we condition the behavior of transaction view on the era; the output will be tailored for babbage (for example ignoring the voters field). Which is weird if the user called cardano-cli conway transaction.

How should I settle this conflict between the era specified by the user and the one inferred from the file on disk?

cc @CarlosLopezDeLara , because this explains the surprising behavior we were observing last Friday.

I would put it under the debug command and we can obtain the era from the tx itself and do "the right thing" depending on the era.

smelc commented 3 months ago

I would put it under the debug command

So: transforming transaction view into debug transaction view?

and we can obtain the era from the tx itself and do "the right thing" depending on the era.

Right now, we are obtaining the era from the tx. So do you want to keep this behavior? Or do you want to have a different behavior according to whether we use debug transaction view or transaction view?

[edit] @Jimbo4350> or should we stop parameterizing transaction view by the era?