-
Notifications
You must be signed in to change notification settings - Fork 5k
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
Comments
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
Have opened a PR fixing the marooned callback in #3285.
Yes. This definitely needs further investigation - thanks so much for raising. |
michaelsbradleyjr
changed the title
Bad return in web3.eth.accounts.signTransaction (?)
Bad return in web3.eth.accounts.signTransaction
Dec 20, 2019
9 tasks
15 tasks
This was referenced Mar 31, 2020
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
See https://github.com/ethereum/web3.js/blob/1.x/packages/web3-eth-accounts/src/index.js#L238.
The inner
signed
function returns from thattry
block, but instead it seems like it should assign the object toresult
. In the case thatreturn
is reached then L252 is not executed. That's what I was running into in #3281 — I finally realized when stepping throughsignTransaction
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: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-incallbackify
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 withawait
or.then
/.catch
.Versions
web3 1.2.4
The text was updated successfully, but these errors were encountered: