myContract.methods.myMethod().send() does not fire the receipt and confirmation events for me.
The transactionHash event is fired, as well as the error event if there is an error. In fact, the "transaction was not mined within 50 blocks" error is fired as well, when in reality the transaction has already been confirmed.
I am using a WebsocketProvider, however I have the same issue with a HttpProvider as well. I have also tried switching to another node, without success.
This is the example code I'm using:
myContract.methods.myMethod(myValue).send({
from: myAddress,
gas: 2500000
})
.on("transactionHash", function () {
console.log("Hash")
})
.on("receipt", function () {
console.log("Receipt");
})
.on("confirmation", function () {
console.log("Confirmed");
})
.on("error", async function () {
console.log("Error");
});
I am using version 1.0.0-beta.36
Edit: Using this code to send the transaction, the events are fired correctly:
web3.eth.sendTransaction({
from: myAddress,
to: myContractAddress,
gas: 2500000,
data: myContract.methods.myMethod(myData).encodeABI()
})
I also have this exact issue right now
Update: upgrading my web3 version to the recent 1.0.0-beta.37 solved it
Hey this has now been fixed on version 1.0.0-beta.37 if you can upgrade and let us know its solved that would be great!
Hey everyone !
I'm coming back on this issue because ia mfacing the same problem.
I am using web3 on version 1.0.0-beta.37 with Metamask to connect on a private Clique-POA node. When submitting a transaction MM ui confirms that it has been mined but web3 does not seem to catch the receipt.
On the other hand if I test my code on a test net like Ropsten it works just fine.
This is because there are missing confirmations for returning a confirmed transaction. With the new Web3.js version (1.0.0-beta.38) which I will release in the next days is it possible to configure the transaction confirmation workflow and I think this will solve your problem. @tchataigner
Is this still an ongoing issue for folks?
We were using 1.0.0-beta.36 and it would take an additional 10-15 seconds for the 'receipt' event to fire after the block was already confirmed. We just attempted to update to 1.0.0-beta.48 and now the 'receipt' event does not fire for multiple minutes, while the 'confirmation' event fires almost immediately inline with the block showing confirmed.
I guess we can move away from use the 'confirmation' event in lieu of using the 'receipt' event instead, but this is pretty kludgy.
Do we know what the source of the issue is? Should I be trying various beta versions between 36-48 to see if one of them is better?
Additionally, the receipt that comes out of the 'confirmation' event is not ABI decoded like the receipt that comes out of the 'receipt' event. Does this need its own issue?
I have the same issue even in 1.0.0-beta.48, only works in sendTransaction and encodeABI.
1.0.0-beta.46 working fine with confirmations, but 1.0.0-beta.47(48, 50) - has an issue
I had the same issue with 1.0.0-beta.37. Turns out that the contract's ABI was outdated and the web3 was failing silently on event parsing. This explains why the sendTransaction works correctly - it doesn't parsing the events. Updating the ABI fixed this issue. Not sure about newer versions..
does not fire receipt in beta51,52
Yeah, I concur.
Event still not fired in beta 52 (the transaction is on Ropsten testnet).
Hi, I am facing the same issue with [email protected];
Only the event once('transactionHash' triggers,
.once('receipt' doesn't trigger
.then(function(receipt) doesn't trigger either
.on('error' triggers and prints an error and transaction object that has status: true
Error: Transaction has been reverted by the EVM:
{
"blockHash": "0x7f1967d80e8006bb867e0cf23d2d61afa7a50234ec30fad8cc476bd06ad2d192",
"blockNumber": 5370174,
"contractAddress": null,
"cumulativeGasUsed": 7400752,
"from": "0x33c391c8ef59bf79b99d8a73d4a8715cd638dd6a",
"gasUsed": 40698,
"logs": [],
"logsBloom": "0x00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000",
"status": true,
"to": "0xcd842ec9601e9056ddf82f587798d71ca0c75acf",
"transactionHash": "0x1921c53ea9ae3e7ea2a72f73367291abd883bfb54f572f546df850fffd3098cd",
"transactionIndex": 78
}
but the transaction is shown successfully completed on Etherscan Ropsten.
Closed because of the ongoing clean up of the issue list. Feel free to ask this in our gitter channel or on stackoverflow.
Not sure why this would get closed without a clarification or linked issue.
If this is because of the transactionConfirmationBlocks property, you could at least call that out. There is still a regression here, at least when I last tested with beta-36: if you set this property on the web3js object it will not be properly set on new contract objects (new contract objects will always have a 24 block conf period, regardless of property setting). It will however set the property properly on existing contract objects.
I'm hitting this same issue, is this behavior documented anywhere?
@nivida Maybe this issue has to be reopened because even in the last release confirmations are not firing.
Two things you have to care for a working solution:
@nivida wait... does it mean I remove .catch from the following code it should become working?
myContract.methods
.someMethod()
.send({
from: ...
})
.on('error', console.log)
.on('transactionHash', console.log)
.on('confirmation', console.log)
.catch(console.log);
@nivida Please clarify how the transaction confirmation workflow should be configured correctly.
const myWeb3 = new Web3(window.web3.currentProvider, null, {
transactionConfirmationBlocks: 10
});
myContract.methods
.someMethod()
.send({ from: 0x... })
.on('error', console.log)
.on('transactionHash', console.log)
.on('confirmation', console.log);
transactionHash only, but confirmations never comesreceipt does not comes tooWhat I am doing wrong?
@nivida
Just for a note.
I have found the source of trouble.
At the start of the my Dapp (after initialization) I had used:
const provider = window.ethereum;
provider.removeAllListeners(); // <<< This call breaks 'confirmation' and 'receipt' callbacks
provider.on('accountsChanged', onAccountChangeActions);
provider.on('networkChanged', onAccountChangeActions);
I changed the call of:
provider.removeAllListeners();
to:
provider.removeListener('accountsChanged', onAccountChangeActions);
provider.removeListener('networkChanged', onAccountChangeActions);
...and all 'confirmation' and 'receipt' become working
Getting the same error here also:
.on('receipt', (receipt) => {
console.log(receipt.contractAddress)
})
No receipt is returned. Also web3.eth.Contract(abi) ______ .then(contractAddress) promise does not work.
@kostysh Thanks for giving me some additional details. These provider methods aren't documented and aren't a part of the public API. If you remove all listeners etc. then you actually remove all listeners and the provider will no longer work. Please use the provided and documented API.
@ShikharBhatt Did you configure the transaction confirmation workflow as described above?
Hey @nivida the option i tried was to change the version to 1.0.0-beta.37 and it works.
Thanks for your answer! @shikharfb
I've refactored the whole library to a more maintainable and extendable architecture after beta.37. Because many projects were relying on the internal architecture of Web3 and didn't use the public API will we (truffle, OpenZeppelin, Nomiclabs, Embark) define beta.37 as 1.0 and the new architecture will be defined as 2.0-alpha. I will write a bigger blog post about when all involved parties of this decision will agree on. I apologize for the confusion but the modernizing of this library was required.
I will be eagerly waiting for the 2.x release. I think there should be a separate versions (semantic minor) for breaking changes. Because a lot of times the patch versions break things and it becomes confusing to consider which ones to use.
I totally agree with you! The goal is to switch to semantic versioning as soon as possible but I need a bit support to maintain 1.0 and 2.0 on the same time:)
Thanks for your patience! @shikharfb
37 works for me best
Been struggling with this for hours.. Started questioning whether I really understood promise then/catching but the then part just wasn't firing at all. Downgrading from beta.55 to beta.37 worked fine just like others have pointed out.
npm uninstall web3
npm install [email protected]
This is like the gift that keeps on giving...
It's 1.2.6 now and i still see this behavior. Sometimes the transactionHash event is never fired
Ia adalah 1.2.6 sekarang dan saya masih melihat kelakuan ini. Kadang peristiwa transaksiHash tidak pernah dipecat
In web3.js 1.2.9 with MetaMask 8.0.2 the following code fires _only_ transactionHash event :-(
contractInstance.methods.pay(itemId).send({from: defaultAccount, value: web3.utils.toWei(String(price*1.0000001)), gas: '1000000'})
.on('transactionHash', function(hash){
console.log('transactionHash');
})
.on('receipt', function(receipt){
console.log('receipt');
})
.on('confirmation', function(confirmationNumber, receipt) {
console.log('confirmation', confirmationNumber);
showFilesWithMessage();
})
.on('error', console.error); // If a out of gas error, the second parameter is the receipt.
Has this been resolved? I'm still experiencing the same issue as @vporton
web3.js 1.2.9 with MetaMask 8.1.5
Still had the same issue on web3.js 1.3.0
@jona-wilmsmann solution worked for me:
web3.eth.sendTransaction({
from: myAddress,
to: myContractAddress,
data: myContract.methods.myMethod(myData).encodeABI()
})
myContract.methods.myMethod.send() appears to be broken
Most helpful comment
Not sure why this would get closed without a clarification or linked issue.
If this is because of the transactionConfirmationBlocks property, you could at least call that out. There is still a regression here, at least when I last tested with beta-36: if you set this property on the web3js object it will not be properly set on new contract objects (new contract objects will always have a 24 block conf period, regardless of property setting). It will however set the property properly on existing contract objects.