Automagically determine the era of cli queries

[Jimbo4350]

• No longer necessary to specify the era when submitting a cli query

[dcoutts]

Looking good! Definitely the right direction.

[dcoutts]

This is better.

At a minimum we should just squash the fixes commit into the first commit before merging.

But there's one more thing I think that's worth thinking about:

This patch expands the code quite a bit still because it does case analysis on the mode and duplicates quite a bit for each mode, whereas the old versions were given the era in an function argument and there were mostly generic in the mode.

I think with a little creativity we could restore that generic approach where we treat all the modes uniformly, and don't have to do case analysis on the mode.

What the old code does is to construct the eraInMode early in each action, and without having to do case analysis on the mode. Of course now we only want to do the automagic era lookup query if we are in a multi-era mode. But I think we can still do that. We just need a helper function that is given the mode and returns the era in mode. That helper function can do case analysis on the mode and return constant eras for the single era modes, or execute the query for the multi-era modes (currently only the CardanoMode of course).

I think it's worth giving this a go. We're going to get more multi-era modes in future (for prototype modes) and it's good to have as much of this code as possible be generic, rather than duplicating per mode.

[dcoutts]

This is fine. Optional suggestions below.

[Jimbo4350]

bors r+

[dcoutts]

Nice.

[iohk-bors]

Build succeeded:

• buildkite/cardano-node
• ci/hydra-build:required
• ci/hydra-eval

[AndrewWestberg]

I don't think --cardano-mode is required any longer.

[Jimbo4350]

It's strictly not required, the default is cardano mode

[gitmachtl]

@dcoutts @Jimbo4350 Do we have a simple method in the future to query the current era of the node? Can we implement an output into the tip json? This was very handy in the past to check the era the node is currently in. In synched mode and during re-syncing.

[gitmachtl]

Is this only for queries but also for transactions? If only for queries, than we please need a method to query the era to use it later.

The current method is a trial and error method to query the protocol-parameters with the different era switches, that one thats not failing is the right era.

How does this work in offline mode? @Jimbo4350

[gitmachtl]

Latest master now dropped the backwards compatibility to at least use the specified era for a query command. Now the cli exits with an error. This breaks all 3rd-Party tools so far and all tutorials again. So, please include the current era in the tip query or in the protocol-parameters query and maybe also reactivate the command line parameters for he query commands to not fail if an era is specified.

[robinboening]

I believe its the right decision to drop the era argument and default to the current 👍

dropped the backwards compatibility to at least use the specified era for a query command. Now the cli exits with an error. This breaks all 3rd-Party tools so far and all tutorials again.

I haven't tried it myself yet, but if this is true it should be highlighted in the release notes as it needs more attention.

It would have been better if the argument was deprecated and will only be removed in the next bigger release, so people would have more time to update their scripts and can go ahead with updating their nodes.

I also recommend to follow semantic versioning which means increasing the major version if an API breaking change is introduced. It makes clear there are breaking changes in the release just by looking at the version number.

✌️

@dcoutts

[gitmachtl]

I haven't tried it myself yet, but if this is true it should be highlighted in the release notes as it needs more attention.

It is in the release notes.. i submitted it yesterday to the team and they included a few additional points in there:
https://github.com/input-output-hk/cardano-node/releases/tag/1.26.1

It is also addressed here on how to do such things in the future:
#2523

[robinboening]

I haven't tried it myself yet, but if this is true it should be highlighted in the release notes as it needs more attention.

It is in the release notes.. i submitted it yesterday to the team and they included a few additional points in there:
https://github.com/input-output-hk/cardano-node/releases/tag/1.26.1

It is also addressed here on how to do such things in the future:
#2523

I saw it in the release notes, but it's not highlighted as a breaking change. I only understood it's breaking because of the comments here. That is what I tried to point out.

[gitmachtl]

the json output of the utxo query also totally changed, also breaking. yes, we had many breaking changes in the past. we (the tool-provider) are dealing with them since the first jormungandr release. i requested a single source of truth a long time ago for 3rd party developers, but thats difficult. meanwhile i dig thru all the code changes as good as i can. because the 3rd party tool development and testing needs time. getting the infos on the release date is way too late. people want to use the new releases with there prefered managment tools. but i also understand that there is no way we get an info on each and every thing the devs are changing in the code, trying out things, etc.... but basically scanning github and checking the repos is the best we get right now.

[robinboening]

but i also understand that there is no way we get an info on each and every thing the devs are changing in the code, trying out things, etc

I do believe it is possible. One common approach is to maintain a CHANGELOG in the root directory and every PR needs to consider if its worth adding a small note. The other part is to follow SemVer. Its simple, it just needs to become part of the process.