aries-cloudagent-python icon indicating copy to clipboard operation
aries-cloudagent-python copied to clipboard

Build integration test support for "Revocation out of sync with accumulator"

Open ianco opened this issue 11 months ago • 2 comments

Related to issue #3546

Aca-py stores revocation in the wallet, and this must be kept in sync with the revocation data on the ledger. Occasionally, if there are issues writing the ledger transactions, these values get out of sync and aca-py is unable to do further revocations. There is logic built-into aca-py to correct these "out of sync" errors, however there have recently been some issues with this logic.

There are no integration tests for this functionality (fixing a "revocation out of sync" error) so no way to ensure that this important logic doesn't break (other than manual testing).

Manual testing involves manually shutting down the ledger (temporarily) which issuing and revoking credentials. It would be better if this could be supported via the integration or scenario tests, and this would ensure continual testing.

The options for this testing support are:

  1. Shutting down and restarting the ledger nodes during the test. This is similar to aca-py restarts that have been incorporated into the scenario tests, however is a bit more complicated as there are four nodes requiring a restart, as well as potentially the web process (in von-network).
  2. Adding a proxy server in front of the nodes - this would allow the shutdown/restart to deal with the proxy server rather than the Indy nodes directly, which would be more straightforward. However the Indy nodes communicate using ZMQ and there are no good proxies available for this protocol.
  3. Updating aca-py to support "unreliable ledgers", by building in logic to deliberately "fail" ledger transactions. This can be built into aca-py directly (and controlled via environment variables, for example) or (preferably) and plug-in could be developed with the capability of deliberately failing a ledger transaction (on request from the client).

The last option (development of a plug-in) is the preferred approach, as this gives maximum control to the integration or scenario test, without any side effects on aca-py deployments (that don't use this plug-in).

The plug-in itself can be a simple copy of the existing LegacyIndyRegistry within acapy/anoncreds, with some additional logic to fail ledger writes (on request). The integration or scenario test can load this plug-in, and block loading of the built-in Indy registry.

The new plug-in can provide new routes which include an additional parameter to specify whether the ledger operation should deliberately fail.

ianco avatar Mar 05 '25 16:03 ianco

@ianco -- I don't think this got done, right? I see a couple of PRs from around when this was fixed, but they don't look like tests.

swcurran avatar Mar 31 '25 23:03 swcurran

No this one didn't get done.

ianco avatar Apr 01 '25 00:04 ianco