Method "tx.wait()" loses context

[sweetpalma]

Recently discovered strange bug on a version 4.0.13. I tried running modifying methods of my contract like that:

const tx = await contract.functions.addPatientContract(userAddress);
await tx.wait();

But encountered the following error:

Unhandled Promise Rejection: TypeError: undefined is not an object (evaluating 'i.interface.parseLog')

I've investigated a bit and found that it may be cause by losing this context on this line: https://github.com/ethers-io/ethers.js/blob/master/src.ts/contract.ts#L283

So I tried to do a direct call without using .functions wrapper - and it worked:

const tx = await contract.addPatientContract(userAddress);
await tx.wait();

It is a pretty minor bug - but it would be great to have this fixed. Thanks for your awesome library anyway - it is really great and a way more concise than web3 is.

[ricmoo]

Absolutely this is a bug. I will get to it right away.

Thanks! :)

[sweetpalma]

Great, thanks!

Just a small related question - is there any way to get the result of the modifying function call? For example, the code of the contract is like that:

function addPatientContract(address userAddress) public returns (address) {
     // some state modification
     return someContractAddress;
}

Is any way to retrieve that someAddress from ethers.js method call? Seems like the only available return option for modifying functions in ethers.js is a pendingtx, am I am right?

[ricmoo]

This isn't possible in Ethereum as a whole, unfortunately.

If you need the value, you will have to log an event. Only a call may return a result to the caller, not a transaction.

If every return value were stored in the state trie it would quickly increase the size of the blockchain unnecessarily, since the vast majority of transactions do not require the return value in the receipt. To store it explicitly, you use a log (called "events" in Solidity), so that the caller pays for it and it is explicitly marked as necessary, and is included in the receipt, optionally indexing it (à la bloom filters) with the indexed keyword, which further increases its cost.

That said, there are usually other ways to solve this problem, such as getters, when eventually consistent is enough (or recoverable, in the case of orphans).

Make sense?

[sweetpalma]

Definitely it does - seems like I missed that part. Thanks a lot!

[ricmoo]

This has been fixed in 4.0.15. Let me know if you still have any issues.

Thanks! :)

[sweetpalma]

Just checked it out - works perfectly on version 4.0.15.

[zemse]

https://cdn.ethers.io/scripts/ethers-v4.min.js still has the 4.0.11 version which has this bug. I generally use webpack, but currently on a project that needed the cdn version. Thanks @sweetpalma for creating the issue, got the temporary solution for now. And thanks @ricmoo for solving!

[ricmoo]

Oh! I’ll update the CDN version shortly. In v5, it is part of the publish operation, so it won’t become out of sync anymore.