This commit fixes the issue that it wasn't possible anymore to use named constructor arguments
in Smart Contract configurations.
For example, the following Smart Contract expects two constructor arguments:
```solidity
contract SomeContract {
constructor(address[] _addresses, int initialValue) public {}
}
```
The first being a list of addresses, the second one a number. This can be configured as:
```js
SomeContract: {
args: [
["$MyToken2", "$SimpleStorage"],
123
]
}
```
Notice how the order of arguments matters here. `_addresses` come first in the constructor,
so they have to be defined first in the configuration as well.
Another way to configure this is using named arguments, which is what's broken prior to this commit:
```js
SomeContract: {
args: {
initialValue: 123,
_addresses: ["$MyToken2", "$SimpleStorage"]
}
}
```
Using a notation like this ^ the order no longer matters as Embark will figure out the right
values for the constructor arguments by their names.
The reason this is broken is because there are several modules in Embark that register and
run a `deployment:contract:beforeDeploy` action, which are allowed to mutate this configuration
object. One of those modules is the `ens` module, which searches for ENS names in the arguments
and figure out whether it has to replace it with a resolved address.
One thing that particular module didn't take into account is that `args` could be either and
array, or an object and will always return an array, changing the shape of `args` in case it was
an object.
This is a problem because another module, `ethereum-blockchain-client`, another action is registered
that takes this mutated object in `determineArguments()` and ensure that, if `args` is actually an
object, the values are put in the correct position matching the constructor of the Smart Contract in
question.
One way to solve this was to use the newly introduced [priority](https://github.com/embark-framework/embark/pull/2031) and ensure
that `ens` action is executed after `ethereum-blockchain-client`'s.
However, the actual bug here is that the ENS module changes the shape of `args` in the first place,
so this commit ensures that it preserves it.
Update event name `"deploy:contract:deployed"` to
`"deployment:contract:deployed"`.
Also, listen one time for `"deployment:deployContracts:afterAll"` and then
request the full contracts list so as to pickup contract names that were
already deployed. This is necessary for subsequent `embark run` (without
reset), otherwise the suggestions list will be missing contracts.
The `WhisperGethClient` returns empty strings for its "new account" and "list
accounts" commands; if a command is an empty string then `Blockchain` should
not execute it.
Those had been removed in a refactor while the Smart Contract sources have been
kept around, resulting in deployment errors as Embark doesn't know what to do
with the Smart Contracts that don't come with a dedicated config.
This commit re-adds the configurations to make the deployment pass again.
Previously, in the embark cli dashboard/console, if you were to type `Foo.` and
hit tab for autocomplete then (assuming you hadn't defined `Foo`) there would
be unhandled errors and the console could even become unusable.
Refactor `packages/core/console` and related code so that nothing happens when
you attempt to autocomplete a bad reference (the same behavior as Node's own
REPL).
Also bump peerDeps: @emotion/core from 0.13.1 to 10.0.22 and @emotion/styled
from 0.10.6 to 10.0.23. Satisfy @babel/runtime peerDep with 7.6.3.
Make small refactors in components/FileExplorer and
containers/FileExplorerRowContainer re: the package upgrades.
Replaces #1998
* fix(@embark/solidity): fix solidity ipc connection with blockchain
When blockchain was run in another process, the IPC was connected,
but the compiler was not loaded, so the IPC calls never returned
* fix(@embark/geth): fix cb is not a fn because it needs request2
As part of the refactor in e330b338ea we've introduced a
second geth client process to enable whisper functionalities in DApps.
This introduced also a new default port for whisper (e330b338ea (diff-a61fbc84e4172487789d676437f26b5fR14)).
This default port has not been introduced on our boilerplate template which is
used in `embark new` when developers scaffold new apps.
This resulted in runtime errors where the geth process for whisper wasn't
able to successfuly boot up as its configured port address is already in use:
```
geth exited with error code 1
geth exited with error code 1
Blockchain process ended before the end of this process. Try running blockchain in a separate process using `$ embark blockchain`. Code: null
```
This commit changes the default port for whisper in the boilerplate template
to ensure apps created using `embark new` don't run into this error anymore.
`embark console` registers and tries to spin up `Cockpit`, even when there's already
a Cockpit instance running and thefore exits with an error that a certain port is already
in use.
This commit ensures that Cockpit is only bootstrapped when `embark console` is
executed as a non-secondary process, meaning that there's no other `embark run`
process active that might occupy Cockpit's default port.
We've introduced a regression in https://github.com/embark-framework/embark/commit/f9557d4c9 where invalid data
has been sent to web3's `ecRecover()` method to verify signed messages.
This causes an internal server error and the utility feature inside Cockpit
unsuable.
This commit ensures that the correct data is sent to `ecRecover()` making verifying
messages through Cockpit functional again.
As discussed in #2008, the `service on/off` command in Embark's interactive console
is non-functioning. As solving the root of the problem requires a bit more effort
than anticipated, we've decided offline to remove this command for the time-being.
The functionality is already gone, this commit removes the corresponding docs.
Fix the proxy’s handling of WebSocket connections when subscribing to contract events and node data using the `eth_subscribe` RPC request.
Previously, the client connection that the subscription data was sent to was often in a closed state. It was determined that this connection was the wrong connection to forward the data in the first place. The connection was in fact generally the connection created for the Ethereum service check which was then (correctly and subsequently) closed after it had finished its operation.
The flow of a proxy request handling a WebSocket “eth_subscribe” RPC request is now as follows:
1. A WebSocket RPC request `”eth_subscribe”` is sent from a client to the proxy.
2. Proxy forwards the request to the node by way of a new instance of `RequestManager`.
3. When the node receives an event matching the subscription, it sends the event data back to same socket connection it received the request on (ie the specific instance of `RequestManager`).
4. The `RequestManager` fires the `”data”` event containing the subscription data, and this event is picked up in the proxy.
5. The proxy then forwards the subscription data on to the originating WS client connection.
All other requests (ie non-WS or WS RPC requests that are not `eth_subscribe`) will be serviced to/from the node using a single `RequestManager` instance.
Co-authored-by: Pascal Precht <pascal.precht@gmail.com>
Embark's `yarn.lock` was pointing to es-abstract@1.14.0 but that's problematic
because that version was unpublished (in the allowed time window). Some of the
npm/yarn registry servers/mirrors (and cloudflare's cache) do make that
version's tarball available for download but not all of them, apparently.
* Revert "fix(@embark/core): set loglevel back to info"
This reverts commit a03ffd56e5.
* Revert "fix(@embark/proxy): Fix contract event subscriptions"
This reverts commit 173d53de2f.
Fix the proxy’s handling of WebSocket connections when subscribing to contract events and node data using the `eth_subscribe` RPC request.
Previously, the client connection that the subscription data was sent to was often in a closed state. It was determined that this connection was the wrong connection to forward the data in the first place. The connection was in fact generally the connection created for the Ethereum service check which was then (correctly and subsequently) closed after it had finished its operation.
The flow of a proxy request handling a WebSocket “eth_subscribe” RPC request is now as follows:
1. A WebSocket RPC request `”eth_subscribe”` is sent from a client to the proxy.
2. Proxy forwards the request to the node by way of a new instance of `RequestManager`.
3. When the node receives an event matching the subscription, it sends the event data back to same socket connection it received the request on (ie the specific instance of `RequestManager`).
4. The `RequestManager` fires the `”data”` event containing the subscription data, and this event is picked up in the proxy.
5. The proxy then forwards the subscription data on to the originating WS client connection.
All other requests (ie non-WS or WS RPC requests that are not `eth_subscribe`) will be serviced to/from the node using a single `RequestManager` instance.
Co-authored-by: Pascal Precht <pascal.precht@gmail.com>
Michael Bradley, Jr
dependabot-preview[bot]
Iuri Matias
Jonathan Rainville
Pascal Precht
emizzle