There was --minimum_viable_task_execution_duration command-line argument was
introduced which is 60s by default. It doesn't respect maxLaunchDelay completely,
and looks like a hack. For instance, if maxLaunchDelay is more than 60s for
some RunSpec, the corresponding rate limiting can be reset/removed, while
the deployment of RunSpec is being delayed.
In addition to that, on conditions like Running, Created, existing delays are
advanced to make sure that delays are applied to failures, and time taken by
provisioning containers doesn't get subtracted from them.
In the future we might implement removal of rate-limiting delays when
a corresponding RunSpec becomes healthy.
I'm finding myself wishing this test were clarified. What, exactly, is it testing" "does X thing after calling resetDelaysOfViableTasks".
further, the stillWaiting variable name seems misleading.
Presume clock is 00:00:00
viable has a back off strategy of 10 seconds, with a max launch delay of 60 seconds. We invoke a delay. This presumably puts the deadline to 00:00:10.
stillWaiting has a back off strategy of 20 seconds, with a max launch delay of 70 seconds. We invoke a delay. This presumably puts the deadline to 00:00:20.
We then advance 61 seconds. The clock is now 00:01:01.
viable's deadline is completely reset, so the current time is returned because it has been in a delayed state for more than 60 seconds. This is sensible.
stillWaiting's deadline is the same as the last time delay was called: 41 seconds ago. I might be misreading this, but that does not seem "stillWaiting".
Is this a realistic simulation for how the component will actually be used?
Would it be better to simulate stepping through time, calling delay multiple times, perhaps 10 seconds at a time, and then asserting in a frame that a delay call, followed by resetDelaysOfViableTasks ceases to have an effect once maxLaunchDelay is reached?
I'm unsure if this would a better way to express the test; but, as it stands, the test is quite confusing.