OverflowError for specific address while fetching token details

[gentrexha]

I've just stumbled upon that self.symbol = token_contract.caller.symbol() is failing for the address 0x8e0E57DCb1ce8d9091dF38ec1BfC3b224529754A.

Full error traceback:

Traceback (most recent call last):
  File "/usr/lib/python3.10/runpy.py", line 196, in _run_module_as_main
    return _run_code(code, main_globals, None,
  File "/usr/lib/python3.10/runpy.py", line 86, in _run_code
    exec(code, run_globals)
  File "/home/gent/Projects/data-misc/src/missing_tokens.py", line 144, in <module>
    run_missing_tokens(chain=blockchain)
  File "/home/gent/Projects/data-misc/src/missing_tokens.py", line 122, in run_missing_tokens
    token_details[token] = TokenDetails(address=token, w3=w3)
  File "/home/gent/Projects/data-misc/src/missing_tokens.py", line 31, in __init__
    self.symbol = token_contract.caller.symbol()
  File "/home/gent/Projects/data-misc/venv/lib/python3.10/site-packages/web3/contract.py", line 1477, in call_function
    return fn(*args, **kwargs).call(transaction, block_identifier)
  File "/home/gent/Projects/data-misc/venv/lib/python3.10/site-packages/web3/contract.py", line 970, in call
    return call_contract_function(
  File "/home/gent/Projects/data-misc/venv/lib/python3.10/site-packages/web3/contract.py", line 1537, in call_contract_function
    output_data = web3.codec.decode(output_types, return_data)
  File "/home/gent/Projects/data-misc/venv/lib/python3.10/site-packages/eth_abi/codec.py", line 210, in decode
    return decoder(stream)
  File "/home/gent/Projects/data-misc/venv/lib/python3.10/site-packages/eth_abi/decoding.py", line 127, in __call__
    return self.decode(stream)
  File "/home/gent/Projects/data-misc/venv/lib/python3.10/site-packages/eth_utils/functional.py", line 45, in inner
    return callback(fn(*args, **kwargs))
  File "/home/gent/Projects/data-misc/venv/lib/python3.10/site-packages/eth_abi/decoding.py", line 173, in decode
    yield decoder(stream)
  File "/home/gent/Projects/data-misc/venv/lib/python3.10/site-packages/eth_abi/decoding.py", line 127, in __call__
    return self.decode(stream)
  File "/home/gent/Projects/data-misc/venv/lib/python3.10/site-packages/eth_abi/decoding.py", line 144, in decode
    stream.push_frame(start_pos)
  File "/home/gent/Projects/data-misc/venv/lib/python3.10/site-packages/eth_abi/decoding.py", line 95, in push_frame
    self.seek_in_frame(0)
  File "/home/gent/Projects/data-misc/venv/lib/python3.10/site-packages/eth_abi/decoding.py", line 84, in seek_in_frame
    self.seek(self._total_offset + pos, *args, **kwargs)
OverflowError: Python int too large to convert to C ssize_t

[gentrexha]

I managed to work around this for the latest missing tokens, but I need to investigate this further to understand why this is happening.

[bh2smith]

In these cases we can insert records manually. They only ever happen once anyway. For example last week I ran into a token that didn't implement the standard erc20 interface, but was still able to pull the details from etherscan. I'm not sure it's worth generalizing the script at the moment to handle obscure case. But maybe in the case of too large int. What's were the specifics of this token making it too large? Was the decimals a large number for the expected size? It's likely this token also doesn't implement erc20 standard and has a different integer type for decimals. Like u32 instead of u8 or something.

[gentrexha]

In these cases we can insert records manually. They only ever happen once anyway. For example last week I ran into a token that didn't implement the standard erc20 interface, but was still able to pull the details from etherscan. I'm not sure it's worth generalizing the script at the moment to handle obscure case. But maybe in the case of too large int. What's were the specifics of this token making it too large? Was the decimals a large number for the expected size? It's likely this token also doesn't implement erc20 standard and has a different integer type for decimals. Like u32 instead of u8 or something.

The decimal number is 18. There wasn't anything special about it I've noticed. I think your assumption about it not implementing the erc20 standard properly is correct.