Multitenancy issue-credential send-request 500 error #1691
Comments
|
Hello there, Ideally you should add the following 4 extra parameters when you start the ACA-Py agent and that should fix your problem:
The 1st one ( it's kind of optional and depends on your setup )... if your profile does not exist it's just gonna try to initialize it for you. The 2nd one is important because the default wallet type is 'basic' and I think you need a propper wallet for storeing more complex things like credential sets. The 3rd and the 4th one is needed because when you pass the wallet type you also need to give it a name and a passphrase decryption key. I think that's it. This should fix the issue for you ;) Goot luck ! |
|
So yes if I provision with those additional flags (in my case passed by envs) it does indeed work. My guess is the This still feels like a bug. I don't really want to need an admin wallet given it represents no real entity in this scenario. Is this in some way by design @shaangill025? I can use this to work around the issue, but at the very minimum a 500 error is still incorrect here |
|
@mattdean-digicatapult If possible, can you please test with the linked PR, this should fix the issue. |
|
Apologies @shaangill025 for the delay. I haven't gotten around to testing this until today. I've rebuilt the docker image off of main and excluded the env variables ( I'm assuming this wasn't expected behaviour? |
Multitenancy issue-credential send-request 500 error
I'm currently working on a proof-of-concept for an SSI system and are running into an issue when switching the credential holder to a multitenancy wallet. When the holder requests a credential (within either the v1 or v2 workflow) the
acapyinstance response with a500error:For reference the PoC orchestration logic (that brings up aca-py and the von-network) can be found here https://github.com/digicatapult/veritable-poc/tree/feature/multitenant-holder.
what version are you using?
We're using
aca-pyversion0.7.3via the bcgov imagebcgovimages/aries-cloudagent:py36-1.16-1_0.7.3hosted on docker hubIn addition we're using the
von-networkas the underlying indy chain.steps to reproduce
von-network, a single tenantacapyfor the issuer and a multitenantacapyfor the holder(s). Note we do this (see orchestration logic linked above) via a start-up script which instantiates two docker-compose stacks (one for thevon-networkand one for theacapyinstances). Also the issuer persona needs to have public DID anchored which we do via anindy-clibased init container.schemafor the credential andcredential-definitionlinking the schema to the issuerindysubwallet for aholderand get atoken/issue-credential-2.0/send-offeror/issue-credential/send-offerwith apropriate content based on theschema/issue-credential/records/{cred_ex_id}/send-requestor/issue-credential-2.0/records/{cred_ex_id}/send-requestas per step 5what do you expect to happen?
The credential request should be sent successfully to the issuer and the api call should have a returned status code of
200.what actually happens
The server does not process the request and responds with status code of
500and a body of:additional information
I've excluded, for brevity, the data passed in the verious API calls becasue this works when not running in multitenancy mode. Therefore I suspect that my workflow and calls are correct (happy to be corrected. If you need any more data on any of the calls let me know. Either way though this shouldn't be a
500error however.I've logged the multitenant
acapyinstance during the final call and get the following:I believe the critical error is at:
which to me implies the
ledgerinstance at that point is somehow invalid and not async-able?apologies if this is all a bit verbose (I had logging turned up pretty high) but hopefully it's useful in diagnosing what's going wrong. Let me know if you need any further information.
The text was updated successfully, but these errors were encountered: