trufflesuite / truffle-core

Core code for Truffle command line tool
MIT License
92 stars 93 forks source link

[TEST] Sporadic ipfshost.js related Test-Failure (EthPM test) #110

Closed ghost closed 6 years ago

ghost commented 6 years ago

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 earlier timeout: 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

ghost commented 6 years ago

Workaround (Failed)

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);

  });
};
ghost commented 6 years ago

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)

ghost commented 6 years ago

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)

ghost commented 6 years ago

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.