This PR increases the reliability of BEvm view methods called from the frontend by sending the request to all the members of the roster. Currently, it was sent only to the first node in the roster, which seems to be unreliable as connection errors appear regularly when using the Stainless demo.
To ensure view methods are executed with a state that is current, the latest block ID is tracked during transaction calls and sent for view methods: using it, the node determines whether it needs to wait for an updated state before executing the call.
π β Friendly checklist:
[x] 0. Code comments are added (or updated) when/where needed and explain the WHY of the code.
[x] 1. Design choices, user documentation and any additional doc are added (or updated) in READMEs.
[x] 2. Any new behaviour is tested and small units of code that can be are unit tested.
[x] 3. Code comments are added on tests to explain what they do.
[x] 4. Errors are systematically wrapped with a meaningful message using xerrors.Errorf and the %v verb.
[x] 5. Hard limit of 80 chars is always respected.
[x] 6. Changes are backward compatible.
[x] 7. Indentation level does not exceed 5, although 4 is already suspicious.
[x] 8. Functions, files, and packages are kept to a manageable size and decomposed into smaller units if needed.
What this PR does
This PR increases the reliability of BEvm view methods called from the frontend by sending the request to all the members of the roster. Currently, it was sent only to the first node in the roster, which seems to be unreliable as connection errors appear regularly when using the Stainless demo. To ensure view methods are executed with a state that is current, the latest block ID is tracked during transaction calls and sent for view methods: using it, the node determines whether it needs to wait for an updated state before executing the call.
π β Friendly checklist:
xerrors.Errorf
and the%v
verb.