Changed the online event to `once` and set it to be bound every time the node goes offline.
The above changes handle the case where:
1) `embark run` runs and starts geth.
2) geth is killed manually
3) `embark blockchain` is run in separate process to restart geth
4) the `embark run` process detects this change and restarts the web3 provider and recompiles/deploys/builds
Every time `embark blochain` is restarted, an error is appended and all are emitted from the `eth-block-tracker`. This is a bug but can't figure out where it originates. The downside is that if, for example, `embark blockchain` is restarted 4 times, there will be 4 errors emitted from the `eth-block-tracker`. Because of this, errors emitted from `eth-block-tracker` have been reduced to trace to avoid clogging the logs.
First case - run `embark run` which starts a blockchain node, then manually kill the `geth` process. Would throw `{ [Error: connect ECONNREFUSED 127.0.0.1:8543] message: 'connect ECONNREFUSED 127.0.0.1:8543', code: -32603 }` error and ruins the dashboard.
Second case, 1) run `embark blockchain` 2) run `embark run` 3) kill `embark blockchain` throws the error `{ [Error: connect ECONNREFUSED 127.0.0.1:8543] message: 'connect ECONNREFUSED 127.0.0.1:8543', code: -32603 }` and ruins the dashboard.
The first case was solved by having the child blockchain process that spawns geth listen for geth exit, then kill itself.
The second case required updating of `eth-block-tracker` to v4.0.1 inside of the `embark-web3-provider-engine`. v4.0.1 was a major version update and introduced breaking changes. Those changes were handled inside of `embark-web3-provider-engine`, covered in **blocker** PR https://github.com/jrainville/provider-engine/pull/1.
First case - run `embark run` which starts a blockchain node, then manually kill the `geth` process. Would throw `{ [Error: connect ECONNREFUSED 127.0.0.1:8543] message: 'connect ECONNREFUSED 127.0.0.1:8543', code: -32603 }` error and ruins the dashboard.
Second case, 1) run `embark blockchain` 2) run `embark run` 3) kill `embark blockchain` throws the error `{ [Error: connect ECONNREFUSED 127.0.0.1:8543] message: 'connect ECONNREFUSED 127.0.0.1:8543', code: -32603 }` and ruins the dashboard.
The first case was solved by having the child blockchain process that spawns geth listen for geth exit, then kill itself.
The second case required updating of `eth-block-tracker` to v4.0.1 inside of the `embark-web3-provider-engine`. v4.0.1 was a major version update and introduced breaking changes. Those changes were handled inside of `embark-web3-provider-engine`, covered in **blocker** PR https://github.com/jrainville/provider-engine/pull/1.
Removed a condition that detects if `mineWhenNeeded === true`. While reaslistically, the `defaultAccount` will only be populated when `mineWhenNeeded` is set, there is no need to check for this when falling back to the blockchain account.
When there is no account/password specified for swarm, there was an error shown in the logs (asking for address/password), and the swarm process would quit.
This PR changes the behaviour so that if a swarm address/password are not specified in the config, it attempts to use the blockchain address/password specified in `config/blockchain > account`. If `config/blockchain > account > address` doesn’t exist, the first account controlled by the node is used (provided by `web3.eth.getAccounts`, along with the password from `config/blockchain > account > password`.
Cargo in fact, bundles up subsequent tasks in to an array, so any tasks that are not immediately run get bundled in to another run later. This helps when lots of changes have been made in a short period of time.
For file changes that do not require a webpack run, ie HTML, the assets will still be copied to the output directory, but webpack will not run (as it’s too slow).