ConwayMempoolFailure is necessarily defined in cardano-ledger. It is Text so that the Consensus Layer can effectively extend the set of possible errors. (Dijkstra is arranged a little differently, but the problem remains.)
However, this means the PredicateFailure type, which has long contains exhaustive information, no longer does. This Issue is to design (perhaps including Ledger) a more robust solution to this problem. For example, if in the future (ie Dijkstra) the MempoolFailure could be parameterized over a type argument for "other" mempool failures, which only the Consensus Layer would actually instantiated.
Switching to Dynamic provides some improved inspectability, but then complicates at least the encoders and decoders.
Perhaps the best option is to remove these upstream "extensibility/open" constructors and change the downstream code to expect more than merely "the ledger type" when dealing with mempool failures. IE the output of a mempool rejection is the type NonEmpty (Either LedgerError ConsensusError)]? At least PR #1831 is an example of a mempool rejection that seemingly should not be upstreamed to Ledger (eg b/c it's pure and is unaware of resource budgets etc).
This would unblock the Consensus change, at the cost of downstream changes in at least the payloads of tracer events and the LocalTxSubmission mini protocol (but ConwayMempoolFailure etc at least provide a fallback during the transition period).
A related option: leave ConwayMempoolFailure as-is, and have the LocalTxSubmission continue to use only that (ie to implement Either LedgerError ConsensusError -> LedgerError), but have the tracers provide the extra information, so they're easier to scrutinize in the downstream tracing logic.
ConwayMempoolFailureis necessarily defined incardano-ledger. It isTextso that the Consensus Layer can effectively extend the set of possible errors. (Dijkstra is arranged a little differently, but the problem remains.)However, this means the
PredicateFailuretype, which has long contains exhaustive information, no longer does. This Issue is to design (perhaps including Ledger) a more robust solution to this problem. For example, if in the future (ie Dijkstra) the MempoolFailure could be parameterized over a type argument for "other" mempool failures, which only the Consensus Layer would actually instantiated.Switching to
Dynamicprovides some improved inspectability, but then complicates at least the encoders and decoders.Perhaps the best option is to remove these upstream "extensibility/open" constructors and change the downstream code to expect more than merely "the ledger type" when dealing with mempool failures. IE the output of a mempool rejection is the type
NonEmpty (Either LedgerError ConsensusError)]? At least PR #1831 is an example of a mempool rejection that seemingly should not be upstreamed to Ledger (eg b/c it's pure and is unaware of resource budgets etc).This would unblock the Consensus change, at the cost of downstream changes in at least the payloads of tracer events and the LocalTxSubmission mini protocol (but
ConwayMempoolFailureetc at least provide a fallback during the transition period).A related option: leave
ConwayMempoolFailureas-is, and have the LocalTxSubmission continue to use only that (ie to implementEither LedgerError ConsensusError -> LedgerError), but have the tracers provide the extra information, so they're easier to scrutinize in the downstream tracing logic.