I'm wondering if this is a change to the default parameters to run an ACA-Py instance that was unexpected. The fix might be to review what the ACA-Py startup parameters are. However, if that is the case, I suspect that the change ought to be to assume that Indy is present and have a new switch to not load it, so we don't break existing deployments. Or is this a breaking change that we want to tell everyone about.
FYI - @nodlesh @ianco @dbluhm
$ ./manage rebuild -a acapy-main
... (success)
$ ./manage run -d acapy-main -t @T003-RFC0023 -v 20
...
When "Bob" sends an explicit invitation with a public DID # features/steps/0023-did-exchange.py:138 0.013s
Assertion Failed: resp_status 500 is not 200; 500 Internal Server Error
and bob_agent.log contains:
2021-05-21 18:03:52,862 aries_cloudagent.core.dispatcher ERROR Handler error: invitation_create
Traceback (most recent call last):
File "/usr/local/lib/python3.7/site-packages/aries_cloudagent/connections/base_manager.py", line 224, in resolve_invitation
doc: ResolvedDocument = await resolver.resolve(self._session.profile, did)
File "/usr/local/lib/python3.7/site-packages/aries_cloudagent/resolver/did_resolver.py", line 60, in resolve
_, doc = await self._resolve(profile, did)
File "/usr/local/lib/python3.7/site-packages/aries_cloudagent/resolver/did_resolver.py", line 45, in _resolve
for resolver in await self._match_did_to_resolver(profile, did):
File "/usr/local/lib/python3.7/site-packages/aries_cloudagent/resolver/did_resolver.py", line 98, in _match_did_to_resolver
raise DIDMethodNotSupported(f'No resolver supprting DID "{did}" loaded')
aries_cloudagent.resolver.base.DIDMethodNotSupported: No resolver supprting DID "did:sov:QbQM5ACo2n9HikwVtMaJoW" loaded
The above exception was the direct cause of the following exception:
Traceback (most recent call last):
File "/usr/local/lib/python3.7/site-packages/aries_cloudagent/protocols/out_of_band/v1_0/routes.py", line 182, in invitation_create
mediation_id=mediation_id,
File "/usr/local/lib/python3.7/site-packages/aries_cloudagent/protocols/out_of_band/v1_0/manager.py", line 231, in create_invitation
endpoint, *_ = await self.resolve_invitation(public_did.did)
File "/usr/local/lib/python3.7/site-packages/aries_cloudagent/connections/base_manager.py", line 228, in resolve_invitation
) from error
aries_cloudagent.connections.base_manager.BaseConnectionManagerError: Failed to resolve public DID in invitation
2021-05-21 18:03:52,863 aries_cloudagent.admin.server ERROR Handler error with exception: Failed to resolve public DID in invitation
Per @moopli -- Looks like a recent change (I suspect this https://github.com/hyperledger/aries-cloudagent-python/pull/1178) has broken aath tests.
I'm wondering if this is a change to the default parameters to run an ACA-Py instance that was unexpected. The fix might be to review what the ACA-Py startup parameters are. However, if that is the case, I suspect that the change ought to be to assume that Indy is present and have a new switch to not load it, so we don't break existing deployments. Or is this a breaking change that we want to tell everyone about.
FYI - @nodlesh @ianco @dbluhm
and bob_agent.log contains: