Graceful tx fail

[tupui]

What problem does your feature solve?

If for some reason sending a tx fails, we need to resubmit it. It might involves recrafting and resigning a tx which can be problematic. E.g. using a Ledger.

What would you like to see?

I would like to get a better error message and at least get the failed XDR. We could even propose the command to run and retry to send the tx.

What alternatives are there?

• Retry as usual. Implies a high churn on users if they use a secret store.
• Add a specific retry command for the last TX.
• Store XDRs in a tmp file and have a command to fetch and present this log. (I actually like this and good for auditability if the CLI is used in a compliant environment.)

[leighmcculloch]

This is partially implemented today, so closing the gap probably wouldn't be a big lift. The CLI has an action log that covers part of alternative 3: successfully submitted transactions are cached to disk, and you can browse them with:

• stellar cache actionlog ls (or -l for timestamps, status, and RPC URL)
• stellar cache actionlog read --id <ULID> to dump the full record, which includes the signed envelope_xdr, result_xdr, result_meta_xdr, and tx_hash

Files live under stellar cache path (the actions/ subdir), so they're available for auditing after the fact. (It's still marked experimental.)

The missing piece for this issue is that the entry is only written after a successful submission. In tx.rs the send polls and returns early on error, before the cache write, so a transaction that fails to send doesn't get its signed XDR captured. Logging the signed envelope before or around submission, so a failed send leaves a retrievable XDR, would build directly on this existing machinery and cover the resubmit-without-resigning case you mention. Would extending the action log this way fit what you had in mind?

[tupui]

Great if that's an easy lift like this. I did not know there was a log. Maybe worth surfacing a bit more in general. E.g. here upon failure it could say that info are in logs.

[leighmcculloch]

Maybe worth surfacing a bit more in general. E.g. here upon failure it could say that info are in logs.

+1, the action log feature is not well known. That's also in part that it is not particularly useful. Once it supports extracting failed transactions I think it could be of more meaningful use. Surfacing it in error messages is a great idea.