When using the WebsocketProvider against the latest Geth (and other versions), web3.js seems to get stuck on the then handler for a transaction.
I can reliably replicate this with the latest beta, and have published a proof of concept here.
Let me know if there are any questions, or if there's anything I can do to help here!
cc. @iurimatias @emizzle
@nivida I am facing same issue here. Any work around for time being?
@andremedeiros and @nivida My one more observation. Transaction does not stuck if sender account has no password. This means it work fine in blow case
let res = await web3.eth.personal.unlockAccount(account1, '')
res = await web3.eth.sendTransaction({ from: account1, to: to, value: 1000000 })
res = await web3.eth.getBalance(to)
console.log('balance', res)
But below doest not work . Execution stuck on sendTransaction line.
let res = await web3.eth.personal.unlockAccount(account2, 'password')
res = await web3.eth.sendTransaction({ from: account2, to: to, value: 1000000 })
res = await web3.eth.getBalance(to)
console.log('balance', res)
Also this work fine if we use httpProvider but not wsprovider
@nivida Do you know any workaround regarding this?
@patidarmanoj10 could you test it with this version it should be fixed: https://github.com/ethereum/web3.js/tree/v1.0.0-beta.38-rc2
This is fixed since beta.38.
The Embark team is still seeing this on beta.52, in a test case that makes use of transactionConfirmationBlocks, per https://github.com/ethereum/web3.js/issues/2640#issuecomment-479480107, because we're running geth --dev.
We're not seeing the problem when using the HTTP provider, only when using websocket.
Most helpful comment
The Embark team is still seeing this on beta.52, in a test case that makes use of
transactionConfirmationBlocks, per https://github.com/ethereum/web3.js/issues/2640#issuecomment-479480107, because we're runninggeth --dev.We're not seeing the problem when using the HTTP provider, only when using websocket.