ACA-Py should perform wallet/ledger operations transactionally - Use atomic transactions

[WadeBarnes]

The following description was copied from here; #2256 (comment)

With ACA-Py it's possible to perform writes to the ledger when it's guaranteed one or more of the operations required will fail, leaving the wallet (secure storage) or the ledger in a state where ACA-Py is unable to recover the record on one, the other, or both sides.

Cases in point:

• ACA-py is out-of-sync with ledger after failed schema/credDef write #2256
• Possible to get in stuck no active registry issuance state #3017

These senecios typically start off with ACA-Py writing to it's wallet and then attempting to write to the ledger, and in some cases a tails server. If any of these operations are interrupted ACA-Py does not attempt to clean up the state, it just throws an error.

ACA-Py should wrap these operations in an atomic transaction to ensure the user has some guarantee that the records are written to both secure storage and the ledger or not at all. That could be as simple as deleting the newly written record from secure storage in the case of a write failure to the ledger, whatever the reason (TAA, ACAPY_READ_ONLY_LEDGER, or network issues). This would eliminate the need for all of prechecks and write failures would be inconsequential since there would be no erroneous records left behind.

[ff137]

Greetings! What is the current state of this issue?

[swcurran]

AFAIK — this is an umbrella issue that is not itself actionable (there is no single “fix” for applying two-phased commits between the wallet and ledger across all interacations), but references and should spawn additional issues to address specific places where the ledger-wallet coordination can be improved. The two example issues in the description are what actually needs to be fixed and AFAIK, they have not been addressed. The only place where significant work has occurred is with “fixing” the wallet and ledger to match after a failed revocation registry accumulator update. That was done a couple of years back, and @jamshale is working on a PR #3299 that addresses an issue with the implementation outlined in #3281.

Not sure how this will ever get closed.