Closed ghost closed 6 years ago
Add the following function to `ipfshost.js', and call it from https://github.com/trufflesuite/ethpm-js/blob/master/lib/preflight.js#L43
This is the only dependency-file fetched during the tests, so test go through fine. Still, the sporadic test failure happens.
IPFSHost.prototype.getDummy = function(uri) {
var self = this;
console.log('->ipfs.getDummy');
return new Promise(function(accept, reject) {
if (uri.indexOf("ipfs://") != 0) {
return reject(new Error("Don't know how to resolve URI " + uri));
}
content = `
{
"lockfile_version": "1",
"version": "1.0.0",
"package_name": "owned",
"meta": {
"license": "MIT",
"authors": [
"Piper Merriam <pipermerriam@gmail.com>"
],
"description": "Reusable contracts which implement a privileged'owner' model for authorization",
"keywords": [
"authorization"
],
"links": {
"documentation": "ipfs://QmQiqrwqdav5bV8mtv4PqGksGcDWo43f7PAZYwhJqNEv2j"
}
},
"sources": {
"./contracts/owned.sol": "ipfs://QmUjYUcX9kLv2FQH8nwc3RLLXtU3Yv5XFpvEjFcAKXB6xD"
}
}
`;
accept(content);
});
};
Next step is to disable all ipfs access, just to be sure (although there is strong indication that Preflight.resolve_dependencies code triggers the sporadic time-out, but only if an dependency is found)
I've provided an ipfs.getDummy, which bypasses ipfs reads completely. But the sporadic error insists.
The package transferable
is usually requested with the id
ipfs://QmNiYhxqk9h1YrKEebasLHRcA8UZVLqbvh1fDTpFyq5Lyi
when the error happens, transferable
is requested with the id:
ipfs://QmZYLL7utWBz9v4nzFsTenKatFRDEsXgTFwHpiy6ADSmHt
This would mean that the error happens when the ipfs-stuff is created pre-test. Or something similar strange (possibly a twisted index).
(will confirm this tomorrow, that 18hours bug-hunting thing today was really too much)
Fresh brain, added the following to the ipfs.getDummy
if (uri === "ipfs://QmZYLL7utWBz9v4nzFsTenKatFRDEsXgTFwHpiy6ADSmHt") {
uri = "ipfs://QmNiYhxqk9h1YrKEebasLHRcA8UZVLqbvh1fDTpFyq5Lyi";
console.log(' #### SPORADIC ERROR CORRECTED ####');
}
which results in this fine debug output:
->ipfs.getDummy: ipfs://QmZYLL7utWBz9v4nzFsTenKatFRDEsXgTFwHpiy6ADSmHt
#### SPORADIC ERROR CORRECTED ####
->ipfs.getDummy: ipfs://QmZ6Zg1iEejuJ18LFczowe7dyaxXm4KC4xTgnCkqwJZmAp
->ipfs.getDummy: ipfs://QmZYLL7utWBz9v4nzFsTenKatFRDEsXgTFwHpiy6ADSmHt
#### SPORADIC ERROR CORRECTED ####
And in passing tests.
The relevant dummy code is here: IPFSgetDummy.js
At this point, debugging becomes much easier (IDE supported debugging), so this SPERR-hunt should be over soon.
One bad news though: another one very very rare sporadic error directly related to ipfs exists (which is possibly windows related). Should be looked into, too.
Work on issue #87 has uncovered that the sporadic test-failures (2nd EthPM test) are not network related. The final cause of the timeout:
The
wget.request
from ipfshost causes the test timeout (default at 15s). Setting an earliertimeout: 10000
for the wget.request a few lines aboves about confirms this.IPFS server: problem is not with the IPFS local server, as the relevant URI gives a normal response from a browser (during the timeout period).
IPFS host: possibly the ipfs client/host code is responsible (hidden errors like connection-resets etc.)
Possible Solutions