Closed viper7882 closed 1 year ago
Are you the admin for the contract? It looks like admin call will revert unless msg.sender
is the admin. From the TransparentUpgradeableProxy contract you linked on Etherscan:
- NOTE: Only the admin can call this function. See {ProxyAdmin-getProxyAdmin}.
I am curious to know the format of the response that you got back though so we can account for that case.
+1 Sometimes requests to some arbitrum node also failed with this error.
PS
Have dug in my logs. Yep, the same node provider, but different chain: https://1rpc.io/arb
Good catch @kclowes. You are absolutely right where the contract is reverted due to ifAdmin
modifier as I'm not the rightful admin. Unbelievable to me someone would have written the contract where only the owner could call and find out who the owner is. Nonetheless, it is still a miss from my end. My apology to you for calling it out as an issue.
However, the second issue remains. Using the codes above, if we print out response
from contract_error_handling.py
file, it should look similar to the following:
{'error': {'code': -32000, 'data': None, 'message': 'execution reverted'},
'id': 1,
'jsonrpc': '2.0'}
In my earlier run, I saw the id
was having a value of 3
whereas the latest run is having a value of 1
. I'm uncertain what does the meaning of the id
is carrying but it seems changing from time to time.
According to JSON-RPC error codes: Errors with codes between -32000 and -32768 are reserved by the JSON-RPC 2.0 specification to indicate a general protocol exception.
Thank you in advance for looking into this issue for me.
Thanks, that response helps. PR is up at #3054.
pip freeze
outputWhat was wrong?
functions.owner().call() to TransparentUpgradeableProxy's implementation contract (i.e. a regular contract) works perfectly by returning address of owner.
functions.admin().call() to TransparentUpgradeableProxy contract is expected to return address of admin but failed miserably with the following issues:
data
inRPCResponse
should not be None. Naturally, None object will not have "startswith" method.Additional Information
Since interaction codes are common for both contract addresses, logically there should not be any behavioral difference between call() made to TransparentUpgradeableProxy contract vs call() made to regular contract.
Despite the code below is targeting Ethereum chain, I have experimented by switching the same code to BSC chain with TransparentUpgradeableProxy contract, issue no. 1 still persist. I am speculating the RPC HTTP endpoint is expecting different
call_transaction
in w3.eth.call() when interacting with TransparentUpgradeableProxy contract.Please include any of the following that are applicable:
from web3 import Web3
def etherscan_common(token_address): chain_rpc_endpoint = "https://1rpc.io/eth" token_ens_address = Web3.to_checksum_address(token_address)
def etherscan_impl():
Etherscan TransparentUpgradeableProxy Implementation
def etherscan_proxy():
Etherscan TransparentUpgradeableProxy
if name == "main": etherscan_impl()