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
In #1774, we introduced executor parameters coherence checks. For most parameters, it includes checking if the parameter's value is within some sensible range. However, we failed to establish such ranges for preparation timeouts (for pre-checking and actual preparation, separately) and execution timeouts (for backing and approvals, separately). What is checked right now is just that the approval timeout is longer than the backing one, and the preparation timeout is longer than the pre-checking one.
It would be good to restrict their values further to some range that makes sense. E.g., zero preparation timeout does not make sense, as well as the backing timeout longer than the block time. It should be a simple change; we just need to figure out what sensible values are.
In #1774, we introduced executor parameters coherence checks. For most parameters, it includes checking if the parameter's value is within some sensible range. However, we failed to establish such ranges for preparation timeouts (for pre-checking and actual preparation, separately) and execution timeouts (for backing and approvals, separately). What is checked right now is just that the approval timeout is longer than the backing one, and the preparation timeout is longer than the pre-checking one.
It would be good to restrict their values further to some range that makes sense. E.g., zero preparation timeout does not make sense, as well as the backing timeout longer than the block time. It should be a simple change; we just need to figure out what sensible values are.
CC @eskimor @burdges @eagr
The text was updated successfully, but these errors were encountered: