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
move executor.status() API boundary to return the cached/mutated data, not fresh provider+simulated data
potentially-refresh cache on every call instead of driven by poller - this might change the refresh cadence.
code that assumes that repeated calls to PollItem.status will be constant, except across the poll loop iteration, might break -- does anything make that assumption? for example: handle_errors vs strategize now happen with potentially different status info (that should be eventually convergent)
the monitoring loop in poll now can't see the update happening/can't get a before/after state inside the loop, because its decoupled now.
probably needs some more persistent (across loop iterations) storage of the previous state...
things to test:
* what test makes sure the provider isn't polled too often?
if not here, write one.
* what tests that we don't scale too much?
(eg. if we ignore the PENDING status added by scale_out
to poller_mutable_status, and let the strategy keep
running, then we should see excessive blocks being
launched)
* test monitoring delta recording works
0 commit comments