[BUG] - Era mismatch on tx submission reports the era where translation got stuck

[palas]

Internal/External
Internal (IOG)

Summary

When you submit a transaction from an older era to a node that is running in a newer era, the node tries to translate the transaction forward, era by era. If the translation fails somewhere along the way, the transaction is rejected with HardForkApplyTxErrWrongEra, but the EraMismatch returned doesn't contain enough information to understand what happened:

• otherEraName seems to contain the era where the translation got stuck, not the era of the transaction that was submitted. For example, I submitted an Alonzo-era transaction to a Dijkstra-era node and the rejection contained ledgerEraName = "Dijkstra" and otherEraName = "Conway". Conway is neither the era of the node nor the era of the transaction, and the submitted era is not included anywhere in the error, so clients have no way to present something sensible to the user. (cardano-cli renders it as: "The node is running in the Dijkstra era, but the transaction is for the Conway era.")
• The reason the translation failed is not included either. In this case, the actual cause was that Dijkstra no longer accepts certificates without deposits, but that information is dropped, so it cannot be discovered from the outside.

The issue seems to be with the EraMismatch produced by the hard-fork mempool (Mempool.hs#L451-L455).

Steps to reproduce

1. Run a network in the Dijkstra era (e.g. TestDijkstraHardForkAtEpoch: 0 in the node config, protocol version 12 in genesis).
2. Build and sign a transaction in an older era that includes a legacy depositless stake registration certificate.
3. Submit it. The rejection reports the transaction as being for the Conway era.

Expected behavior

The rejection should carry the era the transaction was actually submitted in, and ideally also the reason the translation failed, so that clients can produce an accurate message, e.g.:

The node is running in the Dijkstra era. The transaction was submitted as an Alonzo-era
transaction; it could be translated up to Conway, but translation into Dijkstra failed:
Certificates without deposits are no longer supported.

Once the error carries this information, cardano-cli (and other clients) can be updated to give a better error message to the users.

System info

• OS: Linux x86_64
• Consensus version: observed on the leios-prototype fork @ a2583031; the relevant code is the same on main @ 04a5353c

Additional context

The rejection itself seems correct (Dijkstra doesn't allow depositless certificates) — this issue is only about the information carried by the error.

[jasagredo]

If the user knows in which era they submitted the transaction, isn't it enough to render the info as "the transaction only could be translated up to Conway"? Or show a different name for the field?

[palas]

If the user knows in which era they submitted the transaction, isn't it enough to render the info as "the transaction only could be translated up to Conway"? Or show a different name for the field?

Yes, users can work around this issue by using the context.

The reason I make the issue is that EraMismatch error is misleading, since otherEraName is described as "Era of the block, header, transaction, or query." in the docs, but in this case it is not. And also there is the opportunity of giving more info, which would be a nice to have.

In any case, it is a minor issue