Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Indy and Sov DIDs are not resolving -> Empty Pool Config #390

Closed
dennisn00 opened this issue Dec 8, 2023 · 8 comments
Closed

Indy and Sov DIDs are not resolving -> Empty Pool Config #390

dennisn00 opened this issue Dec 8, 2023 · 8 comments

Comments

@dennisn00
Copy link

I set up the Resolver locally in a Docker container and ran
curl -X GET http://localhost:8080/1.0/identifiers/did:indy:idunion:BDrEcHc8Tb4Lb2VyQZWEDE
which is the example for Indy given in the Readme.
This took over a minute and returned
Resolve problem for did:indy:idunion:BDrEcHc8Tb4Lb2VyQZWEDE: A value must be provided for the 'pool' parameter

The same happened for the Sov DID example. I tried a few other DID Methods and they worked fine.
I checked the logs of the driver-did-indy container and it seemed like the environment variable poolConfig was indeed not set.
I saw that in the docker-compose.yml, the poolConfig Environment variable seems to be overwritten with an empty/undefined value.
I removed all those lines as shown below, and restarted the containers.

driver-did-indy:
    image: universalresolver/driver-did-indy:latest  
    #environment:
    #  uniresolver_driver_did_indy_libIndyPath: ${uniresolver_driver_did_indy_libIndyPath}  
    #  uniresolver_driver_did_indy_poolConfigs: ${uniresolver_driver_did_indy_poolConfigs}  
    #  uniresolver_driver_did_indy_poolVersions: ${uniresolver_driver_did_indy_poolVersions}  
    #  uniresolver_driver_did_indy_walletNames: ${uniresolver_driver_did_indy_walletNames}  
    #  uniresolver_driver_did_indy_submitterDidSeeds: ${uniresolver_driver_did_indy_submitterDidSeeds}  
    ports:  
      - "8128:8080"  

This time, the poolConfig was indeed set to the value given in the Driver's Dockerfile. I ran the same curl request and got a
Driver: No resolve result for did:indy:idunion:BDrEcHc8Tb4Lb2VyQZWEDE.
I tried the same DID on https://dev.uniresolver.io/ and received the same result, so I believe this DID might not exist anymore.
I then took the first DID I could find in the Indy Tx Explorer, did:indy:idunion:BNrX6yZzHkKbBGv5aX6PR4, and it
successfully resolved on both, my local instance and https://dev.uniresolver.io/.

I would suggest to remove the lines from docker-compose.yml as shown above unless there is any reason to keep them and update the Readme with a working did:indy: example.

@dennisn00
Copy link
Author

Another solution would be to include the values for the environment variables in .env. I am not sure whether this would have any advantages, but it seems like this is how it is solved for the Sov Driver

@peacekeeper
Copy link
Member

Hello, thanks for your detailed report!

You're right that entries were missing in .env, I just added them in c690f14

I also just updated the example in the README in 7741068.

With regard to the sovrin pool, we will investigate this separately, see also my comment in decentralized-identity/uni-resolver-driver-did-indy#3.

@peacekeeper
Copy link
Member

@dennisn00 could you try again if it works now and if this issue is resolved?

@dennisn00
Copy link
Author

Thanks for you response @peacekeeper. I tested with the sov and indy DIDs provided in the ReadMe. In both cases I got a Error Cannot create Pool Config 'staging'.
I removed the staging/sovrin:staging entries in the .env for indy and sov and now both examples are resolving.
Both are still taking 10 to 60 seconds for resolving (however, subsequent requests to the same DID method but with a different DID are a lot faster). From the logs it seems like all wallets and all Pools are opened on the first request. Is that intentional?

@peacekeeper
Copy link
Member

I removed the staging/sovrin:staging entries in the .env for indy and sov

Hi, I just renamed "staging" to "test" in .env, I think this should work: 4e554e5

From the logs it seems like all wallets and all Pools are opened on the first request. Is that intentional?

Yes that's how we implemented it for now. Perhaps it would make more sense to open the wallets and pools only for a network once it's requests, or maybe all wallets and pools should be opened when the driver starts (before the first request). Or maybe they could all be opened simultaneously in parallel threads, not sure. There's definitely room for improvement.

@dennisn00
Copy link
Author

Yes, it seems to work now. Maybe I will have some time in the next days to try to speed up the wallet and pool opening.

@peacekeeper
Copy link
Member

try to speed up the wallet and pool opening

That would be very welcome of course. This part of the code is mostly in another repo: https://github.com/danubetech/libindy-common-java

@dennisn00
Copy link
Author

Opening Indy connections is now done in parallel and on startup, not on the first resolve request

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants