Couldn't decode _____ from ABI: 0x

[micahalcorn]

Describe the bug

We at Origin are experiencing intermittent bad responses from Web3 reads. The issue seems to be related to passing a specific block number in web3.eth.call rather than 'latest'. It happens intermittently to some users, but it seems to be certainly reproducible on MetaMask 4.16. The bad response is either Couldn't decode address from ABI: 0x or Couldn't decode uint256 from ABI: 0x.

To Reproduce

Request Payload

{id: 2726296308, jsonrpc: "2.0", method: "eth_call",…}
id: 2726296308
jsonrpc: "2.0"
method: "eth_call"
params: [{from: "0xbd6c9914a5853437363d379f4bc01f4c8a06172c",…}, "0x642bbc"]

Response

{"jsonrpc":"2.0","id":2726296308,"result":"0x"}

Expected behavior

curl 'https://api.infura.io/v1/jsonrpc/mainnet' -H 'origin: chrome-extension://nkbihfbeogaeaoehlefnkodbefgpgknn' -H 'accept-encoding: gzip, deflate, br' -H 'accept-language: en-US,en;q=0.9' -H 'user-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/72.0.3588.0 Safari/537.36' -H 'content-type: application/json' -H 'accept: application/json' -H 'authority: api.infura.io' --data-binary '{"id":2726296308,"jsonrpc":"2.0","method":"eth_call","params":[{"from":"0xbd6c9914a5853437363d379f4bc01f4c8a06172c","data":"0xde74e57b0000000000000000000000000000000000000000000000000000000000000013","to":"0x819bb9964b6ebf52361f1ae42cf4831b921510f9"},"0x642bbc"]}' --compressed

{"jsonrpc":"2.0","id":2726296308,"result":"0x000000000000000000000000adc10da9039cbbded8d90cf72626fa9f1a07a5930000000000000000000000000000000000000000000000000000000000000000000000000000000000000000adc10da9039cbbded8d90cf72626fa9f1a07a593"}

Browser details (please complete the following information):

• OS X
• Chrome
• MetaMask Version 4.16

[tmashuang]

Could you expand the params for the requested payload? Possibly a snippet of the source code. My reproduction returned the expected result as the curl.

web3.eth.call({"from":"0xbd6c9914a5853437363d379f4bc01f4c8a06172c","data":"0xde74e57b0000000000000000000000000000000000000000000000000000000000000013","to":"0x819bb9964b6ebf52361f1ae42cf4831b921510f9"}, "0x642bbc", console.log)

{id: 240086479, jsonrpc: "2.0", method: "eth_call",…}
id: 240086479
jsonrpc: "2.0"
method: "eth_call"
params: [{from: "0x3b222de3aaba8ec9771ca9e9af5d8ed757fb7f62",…}, "0x642bbc"]
0: {from: "0x3b222de3aaba8ec9771ca9e9af5d8ed757fb7f62",…}
data: "0xde74e57b0000000000000000000000000000000000000000000000000000000000000013"
from: "0x3b222de3aaba8ec9771ca9e9af5d8ed757fb7f62"
to: "0x819bb9964b6ebf52361f1ae42cf4831b921510f9"
1: "0x642bbc"

Matches the curl

id: 240086479
jsonrpc: "2.0"
result: "0x000000000000000000000000adc10da9039cbbded8d90cf72626fa9f1a07a5930000000000000000000000000000000000000000000000000000000000000000000000000000000000000000adc10da9039cbbded8d90cf72626fa9f1a07a593"

[nick]

The actual call is on this contract: contract.methods.listings(27).call()

This works most of the time, but sometimes will result in the error above.

If you run the following code in the Chrome developer console on https://dapp.originprotocol.com with MetaMask 4.16.0 you should see the issue anywhere from 0-60 seconds in:

let i=0
setInterval(async () => { 
  const result = await originTest.marketplace.resolver.currentAdapter.contract.methods.listings(i++).call() 
  console.log(i, result)
}, 1000)

[bdresser]

thanks for the detail @nick, we're looking.

@kumavis relates to report via Slack here

[bdresser]

@nick @micahalcorn see if this build fixes your issue #5614 (comment)

[nick]

Although the error seems to come up less often... it's still happening:

[RafaelVidaurre]

We seem to be getting this issue as well, @nick did you find any workaround for this?

[olaf89]

I think those invalid responses are also cached by metamask so any kind of retry strategy also fails to work its kind of a big issue

[giltotherescue]

I am also receiving this error intermittently, but frequently, when connected to Main Ethereum Network in Metamask. It happens when I am communicating with a different (non-Origin) smart contract. I do not have any issues when I connect via RPC to my own node.

[jefflau]

I am getting the same thing for the ENS app: https://github.com/ensdomains/ens-app I get it randomly for calls to a Resolver contract or Registrar contract and it is mainly the error: Error: Couldn't decode address from ABI: 0x

I started getting it when I upgraded to web3 1.0. I did not have this problem in web3 0.19, but it sounds similar to @micahalcorn's description.

[zmadmani]

I am also getting this error intermittently for even simple balanceOf calls to ERC20 token contracts. The problem disappears when I am running my own node as well. The caching from metamask also makes it so that once an error has occurred, it is impossible to retry and make progress. The frequency of this issue is quite high from my end, about 1/10 calls fails like this and there seems to be no pattern which of the calls fails (dapp makes a few calls in sequence).

I am currently using web3 1.0 as well and connecting through metamask.

The caching problem in metamask is what is really causing a lot of pain. The fact that it is caching errors makes it difficult to recover. In event of a bad response, is there a way to ignore the cache and force a redo on a call?

[tmashuang]

Related to #5868 (comment)

[danfinlay]

This looks clearly caused by a bug in geth we have reported here:
ethereum/go-ethereum#18254

[adibas03]

@danfinlay @nick
I have been having this issue recently and found that 0x response is regarded as an error where is result is expected as from web3v1.0.0-beta36 and no longer as null(Abi v2)
So, all calls which return 0x would throw that error, meaning the scenario @danfinlay or any scenario that might lead to a 0x response would be the cause.