getChannelIdentifier return data b' ' #4470

Dominik1999 · 2019-07-28T09:38:15Z

Nodes crash with the following error message:

FATAL: An unexpected exception occured. A traceback has been written to /tmp/raiden-exception-2019-07-28T09-330b3vw_72.txt
Could not decode contract function call getChannelIdentifier return data b'' for output_types ['uint256']

Happens from time to time. In this case it is run 46 node 0:
http://scenario-player.ci.raiden.network/Scenario_player_Logs-pfs5_too_low_capacity-1-latest-2019-07-28.tar.gz

@hackaugusto @pirapira had some ideas about that if I am not mistaken.

The text was updated successfully, but these errors were encountered:

pirapira · 2019-07-29T10:01:22Z

Reasons I can think of:

not enough gas
calling a wrong address
one of the addresses is zero
two addresses are the same

hackaugusto · 2019-07-29T10:19:55Z

not enough gas

I hope this is not needed by either parity or geth, the error above was from an eth_call and the spec says the gas is optional. (However, I don't know what web3 is doing)

This is the full stack trace:

jq: error (at <stdin>:383): Invalid numeric literal at line 1, column 10 (while parsing 'Traceback (most recent call last):
  File "/usr/local/lib/python3.7/site-packages/web3/contract.py", line 1372, in call_contract_function
    output_data = decode_abi(output_types, return_data)
  File "/usr/local/lib/python3.7/site-packages/eth_abi/abi.py", line 96, in decode_abi
    return decoder(stream)
  File "/usr/local/lib/python3.7/site-packages/eth_abi/decoding.py", line 118, in __call__
    return self.decode(stream)
  File "/usr/local/lib/python3.7/site-packages/eth_utils/functional.py", line 46, in inner
    return callback(fn(*args, **kwargs))
  File "/usr/local/lib/python3.7/site-packages/eth_abi/decoding.py", line 164, in decode
    yield decoder(stream)
  File "/usr/local/lib/python3.7/site-packages/eth_abi/decoding.py", line 118, in __call__
    return self.decode(stream)
  File "/usr/local/lib/python3.7/site-packages/eth_abi/decoding.py", line 186, in decode
    raw_data = self.read_data_from_stream(stream)
  File "/usr/local/lib/python3.7/site-packages/eth_abi/decoding.py", line 296, in read_data_from_stream
    len(data),
eth_abi.exceptions.InsufficientDataBytes: Tried to read 32 bytes.  Only got 0 bytes

The above exception was the direct cause of the following exception:

Traceback (most recent call last):
  File "/usr/local/lib/python3.7/site-packages/flask/app.py", line 1832, in full_dispatch_request
    rv = self.dispatch_request()
  File "/usr/local/lib/python3.7/site-packages/flask/app.py", line 1818, in dispatch_request
    return self.view_functions[rule.endpoint](**req.view_args)
  File "/usr/local/lib/python3.7/site-packages/flask_restful/__init__.py", line 458, in wrapper
    resp = resource(*args, **kwargs)
  File "/usr/local/lib/python3.7/site-packages/flask/views.py", line 88, in view
    return self.dispatch_request(*args, **kwargs)
  File "/usr/local/lib/python3.7/site-packages/flask_restful/__init__.py", line 573, in dispatch_request
    resp = meth(*args, **kwargs)
  File "/usr/local/lib/python3.7/site-packages/webargs/core.py", line 464, in wrapper
    return func(*args, **kwargs)
  File "/usr/local/lib/python3.7/site-packages/raiden/api/v1/resources.py", line 52, in put
    registry_address=self.rest_api.raiden_api.raiden.default_registry.address, **kwargs
  File "/usr/local/lib/python3.7/site-packages/raiden/api/rest.py", line 612, in open
    registry_address, token_address, partner_address, settle_timeout
  File "/usr/local/lib/python3.7/site-packages/raiden/api/python.py", line 383, in channel_open
    block_identifier=given_block_identifier,
  File "/usr/local/lib/python3.7/site-packages/raiden/api/python.py", line 336, in is_already_existing_channel
    block_identifier=block_identifier or chain_state.client.get_checking_block(),
  File "/usr/local/lib/python3.7/site-packages/raiden/network/proxies/token_network.py", line 423, in get_channel_identifier_or_none
    block_identifier=block_identifier,
  File "/usr/local/lib/python3.7/site-packages/raiden/network/proxies/token_network.py", line 402, in get_channel_identifier
    ).call(block_identifier=block_identifier)
  File "/usr/local/lib/python3.7/site-packages/web3/contract.py", line 1115, in call
    **self.kwargs
  File "/usr/local/lib/python3.7/site-packages/web3/contract.py", line 1394, in call_contract_function
    raise BadFunctionCallOutput(msg) from e
web3.exceptions.BadFunctionCallOutput: Could not decode contract function call getChannelIdentifier return data b'' for output_types ['uint256']')
jq: error (at <stdin>:384): Invalid numeric literal at line 1, column 10 (while parsing 'Traceback (most recent call last):
  File "/usr/local/lib/python3.7/site-packages/web3/contract.py", line 1372, in call_contract_function
    output_data = decode_abi(output_types, return_data)
  File "/usr/local/lib/python3.7/site-packages/eth_abi/abi.py", line 96, in decode_abi
    return decoder(stream)
  File "/usr/local/lib/python3.7/site-packages/eth_abi/decoding.py", line 118, in __call__
    return self.decode(stream)
  File "/usr/local/lib/python3.7/site-packages/eth_utils/functional.py", line 46, in inner
    return callback(fn(*args, **kwargs))
  File "/usr/local/lib/python3.7/site-packages/eth_abi/decoding.py", line 164, in decode
    yield decoder(stream)
  File "/usr/local/lib/python3.7/site-packages/eth_abi/decoding.py", line 118, in __call__
    return self.decode(stream)
  File "/usr/local/lib/python3.7/site-packages/eth_abi/decoding.py", line 186, in decode
    raw_data = self.read_data_from_stream(stream)
  File "/usr/local/lib/python3.7/site-packages/eth_abi/decoding.py", line 296, in read_data_from_stream
    len(data),
eth_abi.exceptions.InsufficientDataBytes: Tried to read 32 bytes.  Only got 0 bytes

The above exception was the direct cause of the following exception:

Traceback (most recent call last):
  File "/usr/local/lib/python3.7/site-packages/flask/app.py", line 1832, in full_dispatch_request
    rv = self.dispatch_request()
  File "/usr/local/lib/python3.7/site-packages/flask/app.py", line 1818, in dispatch_request
    return self.view_functions[rule.endpoint](**req.view_args)
  File "/usr/local/lib/python3.7/site-packages/flask_restful/__init__.py", line 458, in wrapper
    resp = resource(*args, **kwargs)
  File "/usr/local/lib/python3.7/site-packages/flask/views.py", line 88, in view
    return self.dispatch_request(*args, **kwargs)
  File "/usr/local/lib/python3.7/site-packages/flask_restful/__init__.py", line 573, in dispatch_request
    resp = meth(*args, **kwargs)
  File "/usr/local/lib/python3.7/site-packages/webargs/core.py", line 464, in wrapper
    return func(*args, **kwargs)
  File "/usr/local/lib/python3.7/site-packages/raiden/api/v1/resources.py", line 52, in put
    registry_address=self.rest_api.raiden_api.raiden.default_registry.address, **kwargs
  File "/usr/local/lib/python3.7/site-packages/raiden/api/rest.py", line 612, in open
    registry_address, token_address, partner_address, settle_timeout
  File "/usr/local/lib/python3.7/site-packages/raiden/api/python.py", line 383, in channel_open
    block_identifier=given_block_identifier,
  File "/usr/local/lib/python3.7/site-packages/raiden/api/python.py", line 336, in is_already_existing_channel
    block_identifier=block_identifier or chain_state.client.get_checking_block(),
  File "/usr/local/lib/python3.7/site-packages/raiden/network/proxies/token_network.py", line 423, in get_channel_identifier_or_none
    block_identifier=block_identifier,
  File "/usr/local/lib/python3.7/site-packages/raiden/network/proxies/token_network.py", line 402, in get_channel_identifier
    ).call(block_identifier=block_identifier)
  File "/usr/local/lib/python3.7/site-packages/web3/contract.py", line 1115, in call
    **self.kwargs
  File "/usr/local/lib/python3.7/site-packages/web3/contract.py", line 1394, in call_contract_function
    raise BadFunctionCallOutput(msg) from e
web3.exceptions.BadFunctionCallOutput: Could not decode contract function call getChannelIdentifier return data b'' for output_types ['uint256']')

The error happened while the channel was being opened. I think we have two bugs here:

One in the SP that is using invalid addresses.
One in the REST API that is not properly handling the above exception.

Dominik1999 · 2019-07-29T11:53:40Z

@nlsdfnbch can you look into the first bug Augusto mentions here? Should I open a new issue regarding this bug ("SP is using invalid addresses.") in the SP Repo?

karlb · 2019-07-29T13:34:02Z

Does anyone know a way to reliably reproduce this error?

karlb · 2019-07-29T14:46:10Z

This could also be related to a geth bug: ethereum/go-ethereum#19186. Did anyone get this on parity or the latest geth?

Dominik1999 · 2019-07-29T15:21:54Z

hmm we got this on Sunday 28.07. We always checkout the latest dev branch and run raiden on that. Does that help?

Dominik1999 · 2019-07-31T07:33:32Z

@agatsoh is able to reproduce that error. Can you tell us how?

agatsoh · 2019-07-31T07:47:33Z

Yes I run this scenario with the latest version of the scenario player and I get it each time.
https://gist.github.com/agatsoh/21fb9013e5f1106af971d5061aad5774

LefterisJP · 2019-08-05T09:06:57Z

I am taking this issue up. Will investigate for now.

LefterisJP · 2019-08-12T11:13:53Z

@agatsoh need more information from you. I can't reproduce the exception with your scenario using the latest master of raiden.

The scenario does fail, but with a scenario assertion. Not with the error of this isssue.

Your scenario says: raiden_version: local. Which version of raiden are you using?

agatsoh · 2019-08-12T11:49:02Z

Hi @LefterisJP my scenario player is set use the latest nightly as i check my ~/.raiden/scenario-player/raiden_releases/bin/, I find this is my latest binary here

raiden-nightly-2019-07-11T00-19-44-v0.100.5.dev28+ga3b7eba8-linux-x86_64

@nlsdfnbch also has an interesting find here why it is not updating the binaries to the latest raiden version

deepbrook · 2019-08-12T11:54:08Z

The SP has an open PR to update the url for _LATEST file to point to _LATEST-NIGHTLY-<arch>. That PR, unfortunately, wasn't merged when the related PR on the raiden repo was merged, hence it still points at the stale LATEST version @agatsoh was using. The PR has been merged to dev now.

LefterisJP · 2019-08-12T11:56:35Z

So the latest nightly is from over a month ago? Something is wrong there.

Perhaps @nlsdfnbch comment explains why.

So @agatsoh can you try with latest master and this scenario to tell me if you can still reproduce this?

agatsoh · 2019-08-12T12:49:36Z

Yes sure I will try with the latest dev branch in SP

agatsoh · 2019-08-13T06:24:53Z

@LefterisJP So me and @nlsdfnbch both checked this yesterday after Nils merged raiden-network/scenario-player#70 and made some more changes.
One change in the scenario is that now I use raiden_version: latest instead of local.

On the scenario player latest dev when you run the scenario player the OpenChannelTask errors
and in the log file of the scenario (eg for me scenario-player-run_scenario-example-v2-agatsoh_2019-08-12T18:42:21.log) I get the following.

{"task": "<OpenChannelTask: {'from': 1, 'to': 2, 'total_deposit': 1000}>", "event": "Task errored", "logger": "scenario_player.tasks.base", "level": "error", "timestamp": "2019-08-12 13:19:46.376471", "exception": "Traceback (most recent call last):\n  File \"/home/krishna/Envs/raiden_env/lib/python3.7/site-packages/scenario_player/tasks/base.py\", line 74, in __call__\n    return self._run(*args, **kwargs)\n  File \"/home/krishna/Envs/raiden_env/lib/python3.7/site-packages/scenario_player/tasks/api_base.py\", line 59, in _run\n    f'HTTP status code \"{resp.status_code}\" while fetching {url}. '\nscenario_player.exceptions.legacy.RESTAPIStatusMismatchError: HTTP status code \"500\" while fetching http://127.0.0.1:60749/api/v1/channels. Expected 2..: Internal Server Error"}
{"task": "<ParallelTask: {'name': 'Open channels', 'tasks': [{'open_channel': {'from': 0, 'to': 1, 'total_deposit': 1000}}, {'open_channel': {'from': 1, 'to': 2, 'total_deposit': 1000}}, {'open_channel': {'from': 2, 'to': 3, 'total_deposit': 1000}}]}>", "event": "Task errored", "logger": "scenario_player.tasks.base", "level": "error", "timestamp": "2019-08-12 13:19:47.613427", "exception": "Traceback (most recent call last):\n  File \"/home/krishna/Envs/raiden_env/lib/python3.7/site-packages/scenario_player/tasks/base.py\", line 74, in __call__\n    return self._run(*args, **kwargs)\n  File \"/home/krishna/Envs/raiden_env/lib/python3.7/site-packages/scenario_player/tasks/execution.py\", line 65, in _run\n    group.join(raise_error=True)\n  File \"/home/krishna/Envs/raiden_env/lib/python3.7/site-packages/gevent/pool.py\", line 428, in join\n    result = self._empty_event.wait(timeout=timeout)\n  File \"src/gevent/event.py\", line 240, in gevent._event.Event.wait\n  File \"src/gevent/event.py\", line 140, in gevent._event._AbstractLinkable._wait\n  File \"src/gevent/event.py\", line 117, in gevent._event._AbstractLinkable._wait_core\n  File \"src/gevent/event.py\", line 119, in gevent._event._AbstractLinkable._wait_core\n  File \"src/gevent/_greenlet_primitives.py\", line 59, in gevent.__greenlet_primitives.SwitchOutGreenletWithLoop.switch\n  File \"src/gevent/_greenlet_primitives.py\", line 59, in gevent.__greenlet_primitives.SwitchOutGreenletWithLoop.switch\n  File \"src/gevent/_greenlet_primitives.py\", line 63, in gevent.__greenlet_primitives.SwitchOutGreenletWithLoop.switch\n  File \"src/gevent/__greenlet_primitives.pxd\", line 35, in gevent.__greenlet_primitives._greenlet_switch\ngreenlet.GreenletExit"}

After that when you check the nodes individual stderr logs there should be this error


Traceback (most recent call last):
  File "raiden-script.py", line 2, in <module>
  File "raiden/__main__.py", line 13, in main
  File "click/core.py", line 764, in __call__
  File "click/core.py", line 717, in main
  File "click/core.py", line 1114, in invoke
  File "click/core.py", line 956, in invoke
  File "click/core.py", line 555, in invoke
  File "click/decorators.py", line 17, in new_func
  File "raiden/ui/cli.py", line 511, in run
  File "raiden/ui/runners.py", line 244, in run
  File "raiden/ui/runners.py", line 235, in _start_services
  File "src/gevent/greenlet.py", line 849, in gevent._greenlet.joinall
  File "src/gevent/greenlet.py", line 865, in gevent._greenlet.joinall
  File "src/gevent/greenlet.py", line 312, in gevent._greenlet.Greenlet._raise_exception
  File "gevent/_compat.py", line 47, in reraise
  File "src/gevent/greenlet.py", line 716, in gevent._greenlet.Greenlet.run
  File "raiden/ui/runners.py", line 230, in stop_task
  File "src/gevent/greenlet.py", line 633, in gevent._greenlet.Greenlet.get
  File "src/gevent/greenlet.py", line 312, in gevent._greenlet.Greenlet._raise_exception
  File "gevent/_compat.py", line 47, in reraise
  File "src/gevent/greenlet.py", line 716, in gevent._greenlet.Greenlet.run
  File "raiden/api/rest.py", line 408, in _run
  File "gevent/baseserver.py", line 364, in serve_forever
  File "src/gevent/event.py", line 240, in gevent._event.Event.wait
  File "src/gevent/event.py", line 140, in gevent._event._AbstractLinkable._wait
  File "src/gevent/event.py", line 117, in gevent._event._AbstractLinkable._wait_core
  File "src/gevent/event.py", line 119, in gevent._event._AbstractLinkable._wait_core
  File "src/gevent/_greenlet_primitives.py", line 59, in gevent.__greenlet_primitives.SwitchOutGreenletWithLoop.switch
  File "src/gevent/_greenlet_primitives.py", line 59, in gevent.__greenlet_primitives.SwitchOutGreenletWithLoop.switch
  File "src/gevent/_greenlet_primitives.py", line 63, in gevent.__greenlet_primitives.SwitchOutGreenletWithLoop.switch
  File "src/gevent/__greenlet_primitives.pxd", line 35, in gevent.__greenlet_primitives._greenlet_switch
web3.exceptions.BadFunctionCallOutput: Could not decode contract function call getChannelIdentifier return data b'' for output_types ['uint256']
[15439] Failed to execute script raiden-script
--------- Stopped ---------

web3.exceptions.BadFunctionCallOutput: Could not decode contract function call getChannelIdentifier return data b'' for output_types ['uint256']

LefterisJP · 2019-08-13T06:28:43Z

So this is with which raiden version @agatsoh?

agatsoh · 2019-08-13T06:56:05Z

@LefterisJP this one raiden-nightly-2019-08-12T00-23-18-v0.100.5.dev107+g8947e0256-linux-x86_64

LefterisJP · 2019-08-13T11:51:46Z

Thank you @agatsoh . I tried both with that and with the latest nightly, then again with master.

In neither of the runs did what you describe happens for me.

No matter which version I use (nightly or latest master) the scenario fails here:

{"task": "<SerialTask: {'name': 'Check that no IOUs exist and create one', 'tasks': [{'assert_pfs_iou': {'source': 3, 'iou_exists': False}}, {'assert_pfs_history': {'source': 3, 'request_count': 0}}, {'transfer': {'from': 3, 'to': 0, 'amount': 10, 'expected_http_status': >
{"task": "<SerialTask: {'tasks': [{'parallel': {'name': 'Open channels', 'tasks': [{'open_channel': {'from': 0, 'to': 1, 'total_deposit': 1000}}, {'open_channel': {'from': 1, 'to': 2, 'total_deposit': 1000}}, {'open_channel': {'from': 2, 'to': 3, 'total_deposit': 1000}}]}>
{"result": "assertion errors", "event": "Run finished", "logger": "scenario_player.main", "level": "error", "timestamp": "2019-08-13 11:24:49.861393"}
{"event": "Press q to exit", "logger": "scenario_player.main", "level": "warning", "timestamp": "2019-08-13 11:24:49.861897"}
{"shutdown_type": "SIGTERM", "event": "SPaaS Server shutdown", "logger": "scenario_player.services.common.app", "level": "info", "timestamp": "2019-08-13 11:43:29.182007"}
{"event": "Stopping nodes", "logger": "scenario_player.node_support", "level": "info", "timestamp": "2019-08-13 11:43:29.184350"}

And that is a scenario failure, not a raiden failure. I did check all stderr/stdout logs and I can't reproduce this. At least with the versions I tried.

How are you running the scenario player? Which ethereum client is being used underneath?

agatsoh · 2019-08-13T15:45:22Z

@LefterisJP Sorry for late reply I run it like this

scenario_player --chain=goerli:http://10.104.6.13:8545 run --no-ui --keystore-file=/home/krishna/.ethereum/keystore/UTC--2018-10-12T07-01-18.438476520Z--8f2e0940bed6f90f1cb14feb37f045bb79c41b2d --password=${KEYSTORE_PW} ~/raidenforked/scenario-player/scenario-example-v2-agatsoh.yaml

I am also trying to find an answer to which ethereum client does the scenario player use underneath.

LefterisJP · 2019-08-13T15:50:44Z

well you are using infura then? What is http://10.104.6.13:8545?

The argument you are giving up there is how you connect to ethereum.

agatsoh · 2019-08-13T15:52:23Z

aah yes sorry brainfade I am using brainbot VPN nodes. But I dont know exactly what 10.104.6.13 client is under the hood.

agatsoh · 2019-08-13T15:54:54Z

@nlsdfnbch Any idea which ethereum client it is 10.104.6.13. I think you found out once.

LefterisJP · 2019-08-13T16:47:06Z

All right so that is the parity goerli node. 10.104.6.14 is geth. I will try with parity then.

LefterisJP · 2019-08-14T11:05:55Z

Unfortunately even with a parity node and following your steps I can't reproduce this. The same thing I mentioned here happens.

The scenario fails, but only due to a scenario assertion. Raiden does not fail with an exception during channel opening.

I tested with parity, and geth and last 3 nightlies and raiden master.

LefterisJP · 2019-08-14T12:53:44Z

So without reproducing it is hard to say anything concrete. But looking at the code and the stack trace seen above what happens is that the following fails.

        channel_identifier = self.proxy.contract.functions.getChannelIdentifier(
            participant=to_checksum_address(participant1),
            partner=to_checksum_address(participant2),
        ).call(block_identifier=block_identifier)

It returns '' which can't be decoded and that results in BadFunctionCallOutput.

Looking at our TokenNetwork.py code and in web3 the reasons this can happen are the following (also confirmed via tests by me):

Either partner or participant address are 0x0.
Partrner and participant addresses are the same.
The given_block_identifier points to a block at which the TokenNetwork was not yet deployed.

The code is already checking for (1) and (2) here.

So that only leaves (3).

The given block identifier is given below:

raiden/raiden/api/python.py

Lines 394 to 401 in 21467e1

    
           token_network = self.raiden.chain.token_network(token_network_address) 
        
           given_block_identifier = views.state_from_raiden(self.raiden).block_hash 
        
           duplicated_channel = self.is_already_existing_channel( 
        
               token_network_address=token_network_address, 
        
               partner_address=partner_address, 
        
               block_identifier=given_block_identifier, 
        
           )

That means that it's getting the current state block number, which is the latest confirmed block, which should be "latest" minus 5.

At the same time ... right above that code we check if the token network is registered .. but with the latest block! So I can see a potential race there that could lead to this situation.

raiden/raiden/api/python.py

Lines 386 to 387 in 21467e1

    
           registry = self.raiden.chain.token_network_registry(registry_address) 
        
           token_network_address = registry.get_token_network(token_address)

raiden/raiden/network/proxies/token_network_registry.py

Lines 78 to 94 in 21467e1

    
               def get_token_network( 
        
                   self, token_address: TokenAddress, block_identifier: BlockSpecification = "latest" 
        
               ) -> Optional[TokenNetworkAddress]: 
        
                   """ Return the token network address for the given token or None if 
        
                   there is no correspoding address. 
        
                   """ 
        
                   typecheck(token_address, T_TargetAddress) 
        
                   address = self.proxy.contract.functions.token_to_token_networks( 
        
                       to_checksum_address(token_address) 
        
                   ).call(block_identifier=block_identifier) 
        
                   address = to_canonical_address(address) 
        
                   if is_same_address(address, NULL_ADDRESS): 
        
                       return None 
        
                   return address

LefterisJP · 2019-08-14T15:47:35Z

Made a test that reproduces this error in channel_open(). PR incoming with a fix. But still can't be 100% sure it's the same one (even though it most probably is) since I can't reproduce what @agatsoh sees.

Test that opening a channel via the API provides the confirmed block and not the latest block as given_block. The discrepancy there lead to potential timing issues where the token network was deployed for the state in the "latest" block but not yet in the confirmed state and a BadFunctionCallOutput exception was thrown from web3. Regression test for raiden-network#4470 At the moment of this commit where the fix is not yet in the test fails with: ``` web3.exceptions.BadFunctionCallOutput: Could not decode contract function call getChannelIdentifier return data b'' for output_types ['uint256'] ```

- Alsi dissalow default argument for block_identifier for get_token_network. This will only lead to bad surprises. Let's just be explicit Fix raiden-network#4470

Test that opening a channel via the API provides the confirmed block and not the latest block as given_block. The discrepancy there lead to potential timing issues where the token network was deployed for the state in the "latest" block but not yet in the confirmed state and a BadFunctionCallOutput exception was thrown from web3. Regression test for #4470 At the moment of this commit where the fix is not yet in the test fails with: ``` web3.exceptions.BadFunctionCallOutput: Could not decode contract function call getChannelIdentifier return data b'' for output_types ['uint256'] ```

- Alsi dissalow default argument for block_identifier for get_token_network. This will only lead to bad surprises. Let's just be explicit Fix #4470

LefterisJP · 2019-08-16T16:33:13Z

This issue closed assuming that the bug I found here is the reason the issue was made in the first place.

Since I could not reproduce I can't be 100% certain but I would ask to open another issue if something similar is found.

Dominik1999 changed the title ~~Error Scenario Sunday~~ getChannelIdentifier return data b' ' Jul 29, 2019

Dominik1999 self-assigned this Jul 29, 2019

Dominik1999 added the Severity / Minor label Jul 29, 2019

christianbrb assigned czepluch and unassigned Dominik1999 Jul 29, 2019

christianbrb added the State / Investigating For issues that are currently being looked into before labeling further label Jul 29, 2019

palango added this to the Ithaca milestone Jul 29, 2019

christianbrb assigned karlb and unassigned czepluch Jul 31, 2019

karlb removed their assignment Aug 2, 2019

LefterisJP self-assigned this Aug 5, 2019

agatsoh mentioned this issue Aug 12, 2019

error with the pathfinding service Raiden will shut down. Scenario Player local testing raiden-network/raiden-services#513

Closed

Dominik1999 unassigned LefterisJP Aug 13, 2019

LefterisJP self-assigned this Aug 13, 2019

LefterisJP mentioned this issue Aug 14, 2019

Enforce confirmed block usage in api/python.py get_token_network() calls #4606

Merged

11 tasks

christianbrb mentioned this issue Aug 15, 2019

Nightlies Failure 2019-08-15 - BadFunctionCall in runner setup raiden-network/scenario-player#229

Closed

lullis closed this as completed in #4606 Aug 16, 2019

lullis pushed a commit that referenced this issue Aug 16, 2019

Enforce confirmed block in api/python.py get_token_network() calls

ee3336d

- Alsi dissalow default argument for block_identifier for get_token_network. This will only lead to bad surprises. Let's just be explicit Fix #4470

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

getChannelIdentifier return data b' ' #4470

getChannelIdentifier return data b' ' #4470

Dominik1999 commented Jul 28, 2019 •

edited

Loading

pirapira commented Jul 29, 2019

hackaugusto commented Jul 29, 2019

Dominik1999 commented Jul 29, 2019

karlb commented Jul 29, 2019

karlb commented Jul 29, 2019

Dominik1999 commented Jul 29, 2019 •

edited

Loading

Dominik1999 commented Jul 31, 2019

agatsoh commented Jul 31, 2019

LefterisJP commented Aug 5, 2019

LefterisJP commented Aug 12, 2019

agatsoh commented Aug 12, 2019

deepbrook commented Aug 12, 2019

LefterisJP commented Aug 12, 2019

agatsoh commented Aug 12, 2019

agatsoh commented Aug 13, 2019 •

edited

Loading

LefterisJP commented Aug 13, 2019

agatsoh commented Aug 13, 2019 •

edited

Loading

LefterisJP commented Aug 13, 2019

agatsoh commented Aug 13, 2019

LefterisJP commented Aug 13, 2019

agatsoh commented Aug 13, 2019 •

edited

Loading

agatsoh commented Aug 13, 2019

LefterisJP commented Aug 13, 2019 •

edited

Loading

LefterisJP commented Aug 14, 2019

LefterisJP commented Aug 14, 2019

LefterisJP commented Aug 14, 2019

LefterisJP commented Aug 16, 2019

getChannelIdentifier return data b' ' #4470

getChannelIdentifier return data b' ' #4470

Comments

Dominik1999 commented Jul 28, 2019 • edited Loading

pirapira commented Jul 29, 2019

hackaugusto commented Jul 29, 2019

Dominik1999 commented Jul 29, 2019

karlb commented Jul 29, 2019

karlb commented Jul 29, 2019

Dominik1999 commented Jul 29, 2019 • edited Loading

Dominik1999 commented Jul 31, 2019

agatsoh commented Jul 31, 2019

LefterisJP commented Aug 5, 2019

LefterisJP commented Aug 12, 2019

agatsoh commented Aug 12, 2019

deepbrook commented Aug 12, 2019

LefterisJP commented Aug 12, 2019

agatsoh commented Aug 12, 2019

agatsoh commented Aug 13, 2019 • edited Loading

LefterisJP commented Aug 13, 2019

agatsoh commented Aug 13, 2019 • edited Loading

LefterisJP commented Aug 13, 2019

agatsoh commented Aug 13, 2019

LefterisJP commented Aug 13, 2019

agatsoh commented Aug 13, 2019 • edited Loading

agatsoh commented Aug 13, 2019

LefterisJP commented Aug 13, 2019 • edited Loading

LefterisJP commented Aug 14, 2019

LefterisJP commented Aug 14, 2019

LefterisJP commented Aug 14, 2019

LefterisJP commented Aug 16, 2019

Dominik1999 commented Jul 28, 2019 •

edited

Loading

Dominik1999 commented Jul 29, 2019 •

edited

Loading

agatsoh commented Aug 13, 2019 •

edited

Loading

agatsoh commented Aug 13, 2019 •

edited

Loading

agatsoh commented Aug 13, 2019 •

edited

Loading

LefterisJP commented Aug 13, 2019 •

edited

Loading