Ensure consistency in data request execution across libraries

[tmpolaczyk]

PR #2139 fixes a mismatch between the execution of data requests by the node and the execution of data requests using the witnet-toolkit.

We should ensure that there are no more issues like this, by unifying all the "precondition/postcondition" logic in one place and adding tests in all the places that use witnet_rad as a library: node, wallet, cli, toolkit, node tests, ...

[tmpolaczyk]

For example this function is missing the precondition logic, used in data request tests:

witnet-rust/node/tests/data_request_examples.rs

Line 47 in 6504927

fn run_dr_locally_with_data(

[tmpolaczyk]

Another example is the retrieval timeout: the witnet-toolkit does not implement that feature so sometimes it can "hang", breaking the bridge. See witnet/witnet-price-feeds-poller#34

[tmpolaczyk]

Here witnet nodes ensure that less than 20% of the data sources are errors:

witnet-rust/node/src/actors/rad_manager/handlers.rs

Line 80 in 2fa9a2f

evaluate_tally_precondition_clause(retrieve_responses, 0.2, 1, &msg.active_wips);

But the witnet-toolkit seems to use a different percentage, right @guidiaz ?

[guidiaz]

But the witnet-toolkit seems to use a different percentage, right @guidiaz ?

Indeed. Witnet-toolkit solved successfully a 7-source pf, when 2 of them were emitting errors. That is, a 28% of failing sources passed through.

[tmpolaczyk]

It seems that the toolkit is using witnet_rad::try_data_request to execute the data requests, and that function does implement the same 20% check as the node, here:

witnet-rust/rad/src/lib.rs

Line 121 in 2fa9a2f

0.2,

So not sure what could be the cause of the observed behavior.

[tmpolaczyk]

Here witnet nodes ensure that less than 20% of the data sources are errors:

This is not true, that 0.2 is the minimum_consensus: at least 20% of the data sources are not errors. This is equivalent to 80% of the data sources being errors, so it is unlikely to be what's happening here. In that case the data request would resolve to RadError::InsufficientConsensus, so by looking at the specific error we can guess the cause of the inconsistency. But it looks like both the toolkit and the node use the same logic here.

[tmpolaczyk]

Found a possible explanation, see #2306