witnet
Ensure consistency in data request execution across libraries
PR https://github.com/witnet/witnet-rust/pull/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, ...
For example this function is missing the precondition logic, used in data request tests:
https://github.com/witnet/witnet-rust/blob/65049271c91abb75fc3430ee0c9feb45df31698a/node/tests/data_request_examples.rs#L47
Another example is the retrieval timeout: the witnet-toolkit does not implement that feature so sometimes it can "hang", breaking the bridge. See https://github.com/witnet/price_feed_poller/pull/34
Here witnet nodes ensure that less than 20% of the data sources are errors:
https://github.com/witnet/witnet-rust/blob/2fa9a2fdae4501967d739d9884aaaef1882b02da/node/src/actors/rad_manager/handlers.rs#L80
But the witnet-toolkit seems to use a different percentage, right @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.
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:
https://github.com/witnet/witnet-rust/blob/2fa9a2fdae4501967d739d9884aaaef1882b02da/rad/src/lib.rs#L121
So not sure what could be the cause of the observed behavior.
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.