New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Unable to start a node because of a missing status field in receipt #2664

Closed
CosminNechifor opened this Issue Oct 4, 2018 · 12 comments

Comments

Projects
None yet
5 participants
@CosminNechifor
Collaborator

CosminNechifor commented Oct 4, 2018

Problem Definition

My node became unusable and it can no longer start because it crashes with the following stacktrace:

Traceback (most recent call last):
  File "/home/cosmin/.virtualenvs/raiden/bin/raiden", line 11, in <module>
    load_entry_point('raiden', 'console_scripts', 'raiden')()
  File "/home/cosmin/Documents/WORK/GITHUB/raiden/raiden/__main__.py", line 11, in main
    run(auto_envvar_prefix='RAIDEN')  # pylint: disable=no-value-for-parameter
  File "/home/cosmin/.virtualenvs/raiden/lib/python3.6/site-packages/click/core.py", line 722, in __call__
    return self.main(*args, **kwargs)
  File "/home/cosmin/.virtualenvs/raiden/lib/python3.6/site-packages/click/core.py", line 697, in main
    rv = self.invoke(ctx)
  File "/home/cosmin/.virtualenvs/raiden/lib/python3.6/site-packages/click/core.py", line 1043, in invoke
    return Command.invoke(self, ctx)
  File "/home/cosmin/.virtualenvs/raiden/lib/python3.6/site-packages/click/core.py", line 895, in invoke
    return ctx.invoke(self.callback, **ctx.params)
  File "/home/cosmin/.virtualenvs/raiden/lib/python3.6/site-packages/click/core.py", line 535, in invoke
    return callback(*args, **kwargs)
  File "/home/cosmin/.virtualenvs/raiden/lib/python3.6/site-packages/click/decorators.py", line 17, in new_func
    return f(get_current_context(), *args, **kwargs)
  File "/home/cosmin/Documents/WORK/GITHUB/raiden/raiden/ui/cli.py", line 1204, in run
    NodeRunner(kwargs, ctx).run()
  File "/home/cosmin/Documents/WORK/GITHUB/raiden/raiden/ui/cli.py", line 1035, in run
    app = self._run_app()
  File "/home/cosmin/Documents/WORK/GITHUB/raiden/raiden/ui/cli.py", line 1054, in _run_app
    app_ = run_app(**self._options)
  File "/home/cosmin/Documents/WORK/GITHUB/raiden/raiden/ui/cli.py", line 851, in run_app
    raiden_app.start()
  File "/home/cosmin/Documents/WORK/GITHUB/raiden/raiden/app.py", line 139, in start
    self.raiden.start()
  File "/home/cosmin/Documents/WORK/GITHUB/raiden/raiden/raiden_service.py", line 347, in start
    self.raiden_event_handler.on_raiden_event(self, transaction)
  File "/home/cosmin/Documents/WORK/GITHUB/raiden/raiden/raiden_event_handler.py", line 93, in on_raiden_event
    self.handle_contract_send_channelsettle(raiden, event)
  File "/home/cosmin/Documents/WORK/GITHUB/raiden/raiden/raiden_event_handler.py", line 449, in handle_contract_send_channelsettle
    partner_locksroot,
  File "/home/cosmin/Documents/WORK/GITHUB/raiden/raiden/network/proxies/payment_channel.py", line 214, in settle
    partner_locksroot=partner_locksroot,
  File "/home/cosmin/Documents/WORK/GITHUB/raiden/raiden/network/proxies/token_network.py", line 935, in settle
    receipt_or_none = check_transaction_threw(self.client, transaction_hash)
  File "/home/cosmin/Documents/WORK/GITHUB/raiden/raiden/network/rpc/transactions.py", line 8, in check_transaction_threw
    if 'status' not in receipt:
TypeError: argument of type 'NoneType' is not iterable

I want to mention that I am using infura and the tx_hash is: https://ropsten.etherscan.io/tx/0x0ca6dad843243eb1ea0ec9bba58864fc2c20b8a5d749c3585ab9112b9a0349fe
Full log:
log.txt

@hackaugusto

This comment has been minimized.

Collaborator

hackaugusto commented Oct 4, 2018

@CosminNechifor what ethereum client are you using and what is the version? also, what is the actual content of the response?

@palango

This comment has been minimized.

Collaborator

palango commented Oct 4, 2018

As discussed in RC, please test this with the shared geth node to make sure it's not an issue with infura.

@palango

This comment has been minimized.

Collaborator

palango commented Oct 4, 2018

But I guess we should add a None check in check_transaction_threw anyways.

@CosminNechifor

This comment has been minimized.

Collaborator

CosminNechifor commented Oct 4, 2018

If I call for the transaction receipt from infura I get this:

AttributeDict({'blockHash': HexBytes('0xd8c27ea6b0591f11aee3a0dcc9e1c704b687405674e732529b4d94837faa050f'), 'blockNumber': 4169117, 'contractAddress': None, 'cumulativeGasUsed': 1330401, 'from': '0xed3eb09243b7af61538abcf559a444ce869caf0c', 'gasUsed': 58335, 'logs': [AttributeDict({'address': '0x63af692d874724A30C03a69B6C88B3dFBD8c81E0', 'blockHash': HexBytes('0xd8c27ea6b0591f11aee3a0dcc9e1c704b687405674e732529b4d94837faa050f'), 'blockNumber': 4169117, 'data': '0x00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000014', 'logIndex': 10, 'removed': False, 'topics': [HexBytes('0x0e239ef20c651bd0bc45e6f6a5fd46252d77d39d6602103e347add00cabdb0b4'), HexBytes('0x0000000000000000000000000000000000000000000000000000000000000002')], 'transactionHash': HexBytes('0x0ca6dad843243eb1ea0ec9bba58864fc2c20b8a5d749c3585ab9112b9a0349fe'), 'transactionIndex': 14}), AttributeDict({'address': '0x96fF05c6E8C882B16b9Aba4c7685909a436D8Fd7', 'blockHash': HexBytes('0xd8c27ea6b0591f11aee3a0dcc9e1c704b687405674e732529b4d94837faa050f'), 'blockNumber': 4169117, 'data': '0x0000000000000000000000000000000000000000000000000000000000000014', 'logIndex': 11, 'removed': False, 'topics': [HexBytes('0xddf252ad1be2c89b69c2b068fc378daa952ba7f163c4a11628f55a4df523b3ef'), HexBytes('0x00000000000000000000000063af692d874724a30c03a69b6c88b3dfbd8c81e0'), HexBytes('0x00000000000000000000000027fad1fc6bfb2700c06e80fdfd3a8f832f330966')], 'transactionHash': HexBytes('0x0ca6dad843243eb1ea0ec9bba58864fc2c20b8a5d749c3585ab9112b9a0349fe'), 'transactionIndex': 14})], 'logsBloom': HexBytes('0x04000000000000000000000000000000000000000200000000000000400020000000000000000000000000000000000000000000000002000000000000000000000000000000000000000008000000000000200000080000000000000000000000000040800000000000000000000000000000000000000000000010000000000000000000000000000000000020000000000004000000000000000000000000000040000000000000000100000000000080000000000000000000400000000000000002000000000000000000010000000000000000004000000000000000000000000000000000000000000000000000000000008000000000000000000000'), 'status': 1, 'to': '0x63af692d874724a30c03a69b6c88b3dfbd8c81e0', 'transactionHash': HexBytes('0x0ca6dad843243eb1ea0ec9bba58864fc2c20b8a5d749c3585ab9112b9a0349fe'), 'transactionIndex': 14})
@palango

This comment has been minimized.

Collaborator

palango commented Oct 4, 2018

If I call for the transaction receipt I get this:

Again, from infura or a different node?

@hackaugusto

This comment has been minimized.

Collaborator

hackaugusto commented Oct 4, 2018

The first call to eth_gettransactionreceipt returned a null value, a manual subsequent returned some data. So perhaps was it a reorg?

@hackaugusto

This comment has been minimized.

Collaborator

hackaugusto commented Oct 4, 2018

But I guess we should add a None check in check_transaction_threw anyways.

Just checking if it's a None is not that useful, the only thing we could do is to throw a different exception which is a bit more information. I guess the fix for this is to add a default number of confirmations block to all the poll(tx_hash) (assuming the problem was really a reorg)

@CosminNechifor

This comment has been minimized.

Collaborator

CosminNechifor commented Oct 8, 2018

Is weird because after I started the geth node it worked normally. And then I decided to try once Again with infura, and it was no longer breaking.

@LefterisJP

This comment has been minimized.

Collaborator

LefterisJP commented Oct 8, 2018

Assuming this is a reorg. If you can find a reproducible way to handle this then we can reopen. Until then I am closing this as it will be handled by: #2711

@LefterisJP LefterisJP closed this Oct 8, 2018

@palango

This comment has been minimized.

Collaborator

palango commented Oct 9, 2018

I don't think this will be handled by @hackaugusto s PR, this is about requiring a certain number of confirmations in the RPCClient.poll() method.

@palango palango reopened this Oct 9, 2018

palango added a commit to palango/raiden that referenced this issue Oct 9, 2018

Wait for confirmations when polling transactions
Now RPCClient.poll() waits for DEFAULT_NUMBER_OF_CONFIRMATIONS_BLOCK
confirmations by default. This is done to avoid issues like raiden-network#2664

palango added a commit to palango/raiden that referenced this issue Oct 9, 2018

Wait for confirmations when polling transactions
Now RPCClient.poll() waits for DEFAULT_NUMBER_OF_CONFIRMATIONS_BLOCK
confirmations by default. This is done to avoid issues like raiden-network#2664
@LefterisJP

This comment has been minimized.

Collaborator

LefterisJP commented Oct 9, 2018

@palango I see. Good point.

LefterisJP added a commit to palango/raiden that referenced this issue Oct 9, 2018

Wait for confirmations when polling transactions
Now RPCClient.poll() waits for DEFAULT_NUMBER_OF_CONFIRMATIONS_BLOCK
confirmations by default. This is done to avoid issues like raiden-network#2664

palango added a commit to palango/raiden that referenced this issue Oct 10, 2018

Wait for confirmations when polling transactions
Now RPCClient.poll() waits for DEFAULT_NUMBER_OF_CONFIRMATIONS_BLOCK
confirmations by default. This is done to avoid issues like raiden-network#2664

@christianbrb christianbrb assigned rakanalh and unassigned palango Oct 12, 2018

palango added a commit to palango/raiden that referenced this issue Oct 12, 2018

Wait for confirmations when polling transactions
Now RPCClient.poll() waits for DEFAULT_NUMBER_OF_CONFIRMATIONS_BLOCK
confirmations by default. This is done to avoid issues like raiden-network#2664

palango added a commit to palango/raiden that referenced this issue Oct 12, 2018

Wait for confirmations when polling transactions
Now RPCClient.poll() waits for DEFAULT_NUMBER_OF_CONFIRMATIONS_BLOCK
confirmations by default. This is done to avoid issues like raiden-network#2664

rakanalh added a commit to palango/raiden that referenced this issue Oct 15, 2018

Wait for confirmations when polling transactions
Now RPCClient.poll() waits for DEFAULT_NUMBER_OF_CONFIRMATIONS_BLOCK
confirmations by default. This is done to avoid issues like raiden-network#2664

rakanalh added a commit to palango/raiden that referenced this issue Oct 16, 2018

Wait for confirmations when polling transactions
Now RPCClient.poll() waits for DEFAULT_NUMBER_OF_CONFIRMATIONS_BLOCK
confirmations by default. This is done to avoid issues like raiden-network#2664

LefterisJP added a commit that referenced this issue Oct 16, 2018

Wait for confirmations when polling transactions
Now RPCClient.poll() waits for DEFAULT_NUMBER_OF_CONFIRMATIONS_BLOCK
confirmations by default. This is done to avoid issues like #2664
@palango

This comment has been minimized.

Collaborator

palango commented Oct 16, 2018

Fixed by #2731

@palango palango closed this Oct 16, 2018

hackaugusto added a commit to hackaugusto/raiden that referenced this issue Oct 19, 2018

Wait for confirmations when polling transactions
Now RPCClient.poll() waits for DEFAULT_NUMBER_OF_CONFIRMATIONS_BLOCK
confirmations by default. This is done to avoid issues like raiden-network#2664
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment