Scenario failure [13/10/20]: BF1 - Expected request_count 11 but got 10

[palango]

Thanks for filing a bug report :-)

During the nightly run the BF1 scenario failed.

Looks like this is related to https://github.com/raiden-network/raiden/pull/6613 as it passed the run before.

Traceback (most recent call last):
File \"/usr/local/lib/python3.7/site-packages/scenario_player/tasks/base.py\", line 138, in __call__
  raise exception
File \"/usr/local/lib/python3.7/site-packages/scenario_player/tasks/base.py\", line 126, in __call__
  return_val = self._run(*args, **kwargs)
File \"/usr/local/lib/python3.7/site-packages/scenario_player/tasks/api_base.py\", line 66, in _run
  return self._process_response(response_dict)
File \"/usr/local/lib/python3.7/site-packages/scenario_player/tasks/services.py\", line 217, in _process_response
  f\"Expected request_count {exp_request_count} but got {actual_request_count}\"
  scenario_player.exceptions.ScenarioAssertionError: Expected request_count 11 but got 10"}
{"task": "<SerialTask: {'name': 'Check that IOUs exist after the payments', 'tasks': [{'wait': 100}, {'assert_pfs_history': {'source': 3, 'target': 0, 'request_count': 11}}, {'assert_pfs_iou': {'source': 3, 'amount': '550000000000000000'}}, {'assert_pfs_history': {'source': 1, 'target': 4, 'request_count': 10}}, {'assert_pfs_iou': {'source': 1, 'amount': '500000000000000000'}}, {'assert_pfs_iou': {'source': 2, 'iou_exists': False}}]}>", "event": "Task errored", "logger": "scenario_player.tasks.base", "level": "error", "greenlet_name": "orchestration", "timestamp": "2020-10-13 14:50:22.532853", "exception": "Traceback (most recent call last):

Logs: scenario-player-run_bf1_basic_functionality_2020-10-13T14:25:29.log.gz

Expected Result

• Scenario should pass

Remark

• This needs to be fixed on the Raiden Python client side and the scenario needs to be changed back as this it is a capacity check.

[christianbrb]

@karlb Could you please have a look at it. Thanks :) @andrevmatos has got details about it.

[andrevmatos]

@karlb Looks like you guys removed local routing, and changed the expected request_count to 11. We don't have local routing, and yet had it passing before, because even without full network topology, on this specific case, the node can know no local channel is eligible for the requested transfer, and fail before wasting a PFS request which we could know wasn't possible anyway. The reason the scenario failed for us is because we have this optimization, and I think you should implement it too and revert the scenario change: https://github.com/raiden-network/light-client/blob/25bf8e352b6e8d61e0b72cb6c54287a8e378edc3/raiden-ts/src/services/epics.ts#L1068-L1075

[karlb]

Our though was that asking the PFS was acceptable (although not optimal in this case) and the quick and simple way was to allow this in the scenario. We still have to get used to the fact that the light client is running the same scenarios :-)

Adding the same optimization to the python client should not be too hard, so I guess that is what we will do to resolve this.