Problem
Client implementations use caches to optimise epoch processing, the cache management can be broken when new functions are introduced into the process_epoch flow or clients code undergo a refactor. It potentially leads to bugs that are difficult to reveal. One of such examples is #4021.
Existing spec tests cover each epoch processing function in an isolation, this approach misses a class of bugs which can appear when modifications to the beacon state made by one epoch processing function are used by a function down the line. For example, a new validator created during pending deposit processing may not be added to the client’s cache and not handled by effective balance updates as a result.
Potential solution
Create spec tests that covers such scenarios using approach similar to #4024. For instance, if validator’s balance is sufficiently increased/decreased then check that the effective_balance of that validator is updated during the same run of process_epoch.
Problem
Client implementations use caches to optimise epoch processing, the cache management can be broken when new functions are introduced into the
process_epochflow or clients code undergo a refactor. It potentially leads to bugs that are difficult to reveal. One of such examples is #4021.Existing spec tests cover each epoch processing function in an isolation, this approach misses a class of bugs which can appear when modifications to the beacon state made by one epoch processing function are used by a function down the line. For example, a new validator created during pending deposit processing may not be added to the client’s cache and not handled by effective balance updates as a result.
Potential solution
Create spec tests that covers such scenarios using approach similar to #4024. For instance, if validator’s balance is sufficiently increased/decreased then check that the effective_balance of that validator is updated during the same run of
process_epoch.