Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Bad return in web3.eth.accounts.signTransaction #3283

Closed
michaelsbradleyjr opened this issue Dec 19, 2019 · 1 comment · Fixed by #3285
Closed

Bad return in web3.eth.accounts.signTransaction #3283

michaelsbradleyjr opened this issue Dec 19, 2019 · 1 comment · Fixed by #3285
Labels
1.x 1.0 related issues Bug Addressing a bug

Comments

@michaelsbradleyjr
Copy link
Contributor

michaelsbradleyjr commented Dec 19, 2019

See https://github.com/ethereum/web3.js/blob/1.x/packages/web3-eth-accounts/src/index.js#L238.

The inner signed function returns from that try block, but instead it seems like it should assign the object to result. In the case that return is reached then L252 is not executed. That's what I was running into in #3281 — I finally realized when stepping through signTransaction in vscode's debugger.


There is another concern I have about web3.eth.accounts.signTransaction, and I'm not sure how many other function throughout the web3 codebase may be in the same situation. While I'll explain it here, my guess is there should be another issue to discuss the matter more specifically.

So, signTransaction can take a callback, and if none is provided it sets up a dummy callback (cf. L134). However, it always both calls the callback and returns a promise. That's really not good 💣 💥 , but there may be something I've misunderstood so I'm hoping the web3 team can provide feedback on this point.

The implication is that callers that want to use a callback also need to guard against unhandled promise rejections at their call sites, and they should not need to do that. In other words, if I'm passing (err, val) => {...} as the callback then handling of the error should be total with respect to the callback and it should not be necessary to do:

web3.eth.accounts.signTransaction(..., callback).catch(...)

When implementing functions that optionally take a Node.js style callback as the last argument and otherwise return a promise, it might be good to implement with Node's callbackify (src), or the callbackify package may be even better since it handles "callback-mode vs. promise-mode" internally while with Node's built-in callbackify you have to do that yourself.

The main idea is to author all functions/methods that do something asynchronous with a "promise first" mentality. And then consistently provide for callback usage by passing them through callbackify. When used in callback-mode the function/method always returns undefined and err/val handling is total with respect to the callback (which is never called immediately, also very important); while in promise-mode a promise is always returned and the caller needs to use it with await or .then/.catch.

Versions

web3 1.2.4

michaelsbradleyjr added a commit to embarklabs/embark that referenced this issue Dec 19, 2019
Refactor typings as necessary. In order for `bignumber.js` in the root
`node_modules` to not conflict with `@types/bignumber.js`, specify
`"bignumber.js": "5.0.0"` in `devDependencies` and `"embark-ui/bignumber.js"`
in `nohoist` of the root `package.json`.

In `packages/plugins/rpc-manager` switch from callback to promise usage with
respect to `web3.eth.accounts.signTransaction` because of a [bug][bug]
discovered in web3 v1.2.4.

In `packages/plugins/solidity-tests` specialize the tsc compiler options with
`"skipLibCheck": true` because of a problematic web3-related typing in the
`.d.ts` files of the remix-tests package.

Bump ganache-cli from 6.4.3 to 6.7.0 (latest) because 6.4.3 doesn't support
`eth_chainId` but web3 1.2.4 makes use of the `eth_chainId` RPC method (EIP
695).

BREAKING CHANGE: bump embark's minimum supported version of parity from
`>=2.0.0` to `>=2.2.1`. This is necessary since web3 1.2.4 makes use of the
`eth_chainId` RPC method (EIP 695) and that parity version is the earliest one
to implement it.

[bug]: web3/web3.js#3283
michaelsbradleyjr added a commit to embarklabs/embark that referenced this issue Dec 20, 2019
Refactor typings as necessary. In order for `bignumber.js` in the root
`node_modules` to not conflict with `@types/bignumber.js`, specify
`"bignumber.js": "5.0.0"` in `devDependencies` and `"embark-ui/bignumber.js"`
in `nohoist` of the root `package.json`.

In `packages/plugins/rpc-manager` switch from callback to promise usage with
respect to `web3.eth.accounts.signTransaction` because of a [bug][bug]
discovered in web3 v1.2.4.

In `packages/plugins/solidity-tests` specialize the tsc compiler options with
`"skipLibCheck": true` because of a problematic web3-related typing in the
`.d.ts` files of the remix-tests package.

Bump ganache-cli from 6.4.3 to 6.7.0 (latest) because 6.4.3 doesn't support
`eth_chainId` but web3 1.2.4 makes use of the `eth_chainId` RPC method (EIP
695).

BREAKING CHANGE: bump embark's minimum supported version of parity from
`>=2.0.0` to `>=2.2.1`. This is necessary since web3 1.2.4 makes use of the
`eth_chainId` RPC method (EIP 695) and that parity version is the earliest one
to implement it.

[bug]: web3/web3.js#3283
@cgewecke
Copy link
Collaborator

Have opened a PR fixing the marooned callback in #3285.

the callback then handling of the error should be total with respect to the callback and it should not be necessary to do:

Yes. This definitely needs further investigation - thanks so much for raising.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
1.x 1.0 related issues Bug Addressing a bug
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants