Provide an 'EpochInfo' that can fail to ledger.

[nc6]

The ledger now supports an EpochInfo (Either Text), and uses the
Left constructor to indicate a horizon error. Unfortunately, while the
epoch info being provided had the correct type, it was implemented in
a degenerate way - the Left constructor would never be used and
instead a pure error was thrown on failures.

This PR instead provides a correct EpochInfo to the ledger, where the
failure is reflected in the Left constructor.

[dcoutts]

LGTM.

To be more comprehensive I think we should audit the other uses of toPureEpochInfo, and indeed perhaps rename it to make it clear it throws exceptions. We should file a TODO issue for that, it doesn't need to be in this PR of course.

[nc6]

I did go through the other uses of toPureEpochInfo and think they are all legit. We otherwise use it only for epoch/slot computations for the current slot.

[nc6]

bors merge

[nfrisby]

Hmm. I wonder if SL.mkShelleyGlobals used to take a pure EpochInfo and was changed to take an Either one, and the integration PR for that changed missed this because toPureEpochInfo is polymorphic.

So, we could try changing toPureEpochInfo to return Identity instead of Applicative f => f to try to prevent similar from happening again.

I created https://input-output.atlassian.net/browse/CAD-4433 for this tech debt ^^^.

[nfrisby]

I did go through the other uses of toPureEpochInfo and think they are all legit. We otherwise use it only for epoch/slot computations for the current slot.

I see a few remaining uses of toPureEpochInfo.

• tickChainDepState @Praos passes it to isNewEpoch to check whether we're ticking past an epoch boundary. It converts the slot we're ticking to an epoch (which could fail) and compares epochs -- I think it should instead convert the end of the current epoch to a slot (which can't fail) and then compare slots

• checkIsLeader @TPraos uses it to compute the firstSlot of the epoch of the given slot when calling SL.lookupInOverlaySchedule firstSlot .... As in the previous case, that translation can also fail, but I don't see an alternative that can't fail.

• tickChainDepState @TPraos uses it as does tickChainDepState @Praos above

So I think we should fixup the tickChainDepState calls to use unfailing translations instead of failing translations.

[iohk-bors]

Timed out.

[nc6]

bors retry

[iohk-bors]

Build succeeded:

• build (8.10.7, ubuntu-20.04)
• build (8.10.7, windows-latest)
• ci/hydra:Cardano:ouroboros-network:required