You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Perhaps #439 simplified the error messages assigned to the data results too much. Testing using the new integration testing, I suspect the base error was "> 1/3 of reveals are corrupted" here. Since 1 out of 1 reveal had a non-zero exit code, ApplyFilter() returned an error and tally VM was not executed. When tally VM is not executed, the consensus is always false as described here (Corrupt reveals error is distinct from no consensus error). Looks like we will have to modify the filtering logic.
We agreed to take time this week to work on the entire tally specification including rewards so we can pick these issues up together. We'll update the Notion document (or create a new one) with a flowchart detailing the various states that can come into the tally state machine, the checks it should do, and the outcome we expect in terms of consensus, exit codes, and payouts.
🐛 Bug Report
Thinking a little more I'm pretty sure this actually has to do with determining consensus/outcomes for non-zero exit codes.
When tallying reveals for executions that ran out of gas the chain incorrectly returns a
failed to apply filter
error.See https://devnet.test.explorer.seda.xyz/data-requests/d5d6d3dd1f41f6e23bd7a35c54bf85a2efd45d9c926c4845beb9c8441f8b4bfc/2394 for an example
Steps to Reproduce
Post a DR with a low
exec_gas_limit
.Code snippet to reproduce
Stack trace & error message
Expected Behavior
If all reveals are non-zero we can still have consensus; it's just that the outcome is an error.
Your Environment
The text was updated successfully, but these errors were encountered: