parity-js / api Goto Github PK

E.g.

contract C {
  function myFunc(uint input) returns (uint) {
    revert();
  }
}

// setup api and get contract
const res = await C.instance.myFunc.call({}, [3]); // returns 0 rather than throwing error

Feel free to close this as invalid if you think the semantics of parity.js call should be to return the default when the call fails, but it seems like throwing an error is more appropriate here.

This is issue is a follow up for the one in the old repo issue. The number of rpc calls of the polling method makes impossible to us to use api.subscribe.

Using this on a Nodejs environment, and using Websocket transport, it throws an error regarding window is not defined. This only happens if it get disconnect and tries to reconnect, or when you get an error from the response.
This window error comes from this lines.

If I define a contract with an overloaded function, then try to call the function from the parity.js contract instance, I can only access one of the functions by name.

e.g.

contract C {
  function myFunc(address a) { return; }
  function myFunc(address a, uint b) { return; }
}

// after getting contract instances
theContract.instance.myFunc.call({}, ['0x0']); // errors due to missing property in array
theContract.instance.myFunc.call({}, ['0x0', 22]); // works fine

Workaround right now is to use the function signature bytes, (something like theContract.instance.be45fd62.call) which are different for each of the functions.

The code that causes this behaviour is here, where the value of the property corresponding to the function name is overwritten.

One possible fix would be to make contract.instance.myFunc dynamically determine which signature should be called based on the types of the arguments, and then call with the correct function signature based on that. The issue I see with this approach is that js is not typed the same way solidity is, so inferring the types may not be accurate.

Edit:

Seems like web3 handles it like this (setting key as func(argType1,argType2)), and this (choosing the function with the correct "shape" of parameters, if only one such function exists).

I believe the @parity/api-interface (and especially the oo7 Bonds wrapper around it) are a marvellous way to write Decentralized Applications that is greatly preferable over manually short-polling the Ethereum Wallet for changes every couple of seconds.

However, @parity/api currently is only built in such a way that it works well with a locally running lite or full wallet that is exposed over localhost:8545. Especially users of MetaMask (which, although it of course has its limitations, is a gradual introduction into the Ethereum ecosystem), or users that browse the app directly in Mist, will inject their own Web3, and their own Provider.

Now it seems to me that the web3.currentProvider that is injected follows the same API as the Api.Provider object that @parity/api expects. However, this is based on duck-typing and also I have only verified this on a superficial level during the Blockchaingers Hackathon last week.

// sets up Bonds in a way that is compatible with MetaMask (and hopefully Mist as well)
import {bonds, options as bonds_options} from 'oo7-parity';
import Api from '@parity/api';
import BundledWeb3 from 'web3';

var provider;
var parityapi;
var web3;
window.addEventListener('load', function() {

    // Checking if Web3 has been injected by the browser environment
    if (typeof window.web3 !== 'undefined') {
        // Use the browser's ethereum provider
        window.provider = provider = window.web3.currentProvider
        web3 = window.web3;
        window.parityapi = parityapi = new Api(provider) // <- Fingers crossed!
        bonds_options.api = parityapi
    } else {
        // Use bundled Web3 that assumes a wallet is running locally at port 8545
        window.provider = provider = new BundledWeb3.providers.HttpProvider("http://localhost:8545");
        window.web3 = web3 = new BundledWeb3(provider);
    }
});

export {bonds, bonds_options, web3};

(The window.* assignments are there for debugging purposes, and to make sure that the stuff that was already injected in this global context is also properly wrapped)

Would this (or probably: something based on this) be the proper way to ensure that @parity/api works with other wallets as well? Or should a different approach be taken?

Input:

await api.personal.unlockAccount('0x35703012d6d353c33ef006c22dfd04a04dd6523a', 'password', 0);

Output:

personal_unlockAccount(["0x35703012d6d353c33ef006c22dfd04a04dd6523a","password",0]): -32602: Invalid params: invalid type: integer `0`, expected a 0x-prefixed, hex-encoded number of length 32.
(node:8567) UnhandledPromiseRejectionWarning: Unhandled promise rejection (rejection id: 1): TransportError: personal_unlockAccount: -32602: Invalid params: invalid type: integer `0`, expected a 0x-prefixed, hex-encoded number of length 32.
(node:8567) [DEP0018] DeprecationWarning: Unhandled promise rejections are deprecated. In the future, promise rejections that are not handled will terminate the Node.js process with a non-zero exit code.

May be due to calling inNumber10 here? I can see that throwing an error if the RPC endpoint expects something in hex.
Perhaps it should be inNumber16 instead.

(node:22916) UnhandledPromiseRejectionWarning: ReferenceError: window is not
 defined
    at Object.<anonymous> (/home/logan/.nvm/versions/node/v9.3.0/lib/node_modul
es/eac.js/node_modules/@parity/api/lib/provider/ipc.js:20:19)
    at Module._compile (module.js:660:30)
    at Object.Module._extensions..js (module.js:671:10)
    at Module.load (module.js:573:32)
    at tryModuleLoad (module.js:513:12)
    at Function.Module._load (module.js:505:3)
    at Module.require (module.js:604:17)
    at require (internal/module.js:11:18)
    at Object.<anonymous> (/home/logan/.nvm/versions/node/v9.3.0/lib/node_modul
es/eac.js/node_modules/@parity/api/lib/provider/index.js:18:11)
    at Module._compile (module.js:660:30)

The code using Parity API package:

const hasPendingParity = async (conf, txRequest) => {
	/// Only available if using parity locally.
	const pApi = require("@parity/api")
	const provider = new pApi.Provider.Http(`${conf.provider}`)
	const api = new pApi(provider)

	const transactions = await api.parity.pendingTransactions()
	const recips = transactions.map(tx => tx.to)
	if (recips.indexOf(txRequest.address) !== -1) return true
	return false
}

As far as I can tell this has to do with the IPC provider which was added in the latest release. I'm going to downgrade since this was last working on version 2.1.16.

Could be useful to add a timed-out error in the PostMessage provider if no response has been received for more than N seconds.