Fixes issue where importing jolocom-lib would lead to some async code running in the background that wouldn't get cleaned up. This would show up in jest with it complaining about:
Jest did not exit one second after the test run has completed.
This usually means that there are asynchronous operations that weren't stopped in your tests. Consider running Jest with `--detectOpenHandles` to troubleshoot this issue.
I tracked this down to jolo-did-method and ethers.js, here's an explanation:
When you create a provider with ether.js it will try and create a connection to the given url, it does this very non obviously so when you do
const provider = new ethers.providers.JsonRpcProvider(infura);
it will try and hit the url in the background until it succeeds in setting up a connection. You're meant to call provider.ready which returns a promise you can block on until the connection is created. If you don't block on it and it takes a long time to set up the connection, then when your test ends - jest will complain. This issue started cropping up because the infura url no longer works, so ethers just constantly retries connecting to it in the background.
So the call stack (in reverse) looks like
jolo-did-method calls new ethers.providers.JsonRpcProvider(infura) when getRegistrar() or getResolver() is called.
jolocom-lib calls 'getRegistar` when the JoloDidMethod constructor is called.
new JoloDidMethod() gets called when the didMethods constant is exported
Hence simply importing jolocom-lib winds up calling new ethers.providers.JsonRpcProvider(infura) and causing this problem.
To make the issue less of a problem for now i made it so the did-jolo resolver calls getResolver() lazily, interestingly enough the did-jolo registrar already calls getRegistrar lazily so I basically just used the same approach in the resolver. I also changed the default provider url to one that works.
This doesn't solve the issue completely, if you actually use did-jolo to resolve and register stuff, and the url you use takes a while to connect, then you open yourself up to this issue. But at least now it won't appear when you're not even using did-jolo.
Fixes issue where importing jolocom-lib would lead to some async code running in the background that wouldn't get cleaned up. This would show up in jest with it complaining about:
I tracked this down to jolo-did-method and ethers.js, here's an explanation:
When you create a provider with ether.js it will try and create a connection to the given url, it does this very non obviously so when you do
const provider = new ethers.providers.JsonRpcProvider(infura);it will try and hit the url in the background until it succeeds in setting up a connection. You're meant to call provider.ready which returns a promise you can block on until the connection is created. If you don't block on it and it takes a long time to set up the connection, then when your test ends - jest will complain. This issue started cropping up because the infura url no longer works, so ethers just constantly retries connecting to it in the background.
So the call stack (in reverse) looks like
new ethers.providers.JsonRpcProvider(infura)whengetRegistrar()orgetResolver()is called.new JoloDidMethod()gets called when thedidMethodsconstant is exportednew ethers.providers.JsonRpcProvider(infura)and causing this problem.To make the issue less of a problem for now i made it so the did-jolo resolver calls
getResolver()lazily, interestingly enough the did-jolo registrar already callsgetRegistrarlazily so I basically just used the same approach in the resolver. I also changed the default provider url to one that works.This doesn't solve the issue completely, if you actually use did-jolo to resolve and register stuff, and the url you use takes a while to connect, then you open yourself up to this issue. But at least now it won't appear when you're not even using did-jolo.