You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
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).
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.
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.
The text was updated successfully, but these errors were encountered:
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:
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.
The text was updated successfully, but these errors were encountered: