Refactor: track compute zones bans and round-robin cursor in a separate component. #9105
Conversation
|
|
||
| /// Executes [fn] in compute [zone] and handles zone-related exceptions | ||
| /// with the appropriate bans. | ||
| Future<void> withZoneAndInstance( |
There was a problem hiding this comment.
let's not move this logic. Do we need to?
The interactions here are subtle, this is not reusable, and shouldn't attempt to be.
Whether to ban or not ban a zone is a scheduling decision.
I'm not keen on ComputeZoneTracker being mutable, nor am I keen on it containing much logic. Isn't it mostly just a container for state between iterations.
Keeping state immutable, means runSchedulerIteration (I assume we are working towards) will have to return a new state object, that it can mutate with timers after returning it.
I think spreading logic across files will make it harder to track.
wouldn't it be better for runSchedulerIteration to return a ZoneTrackerState object? that is effectively immutable.
|
Closing as it is planned to be done differently. |
2 participants
No description provided.