Note that both suites have the same priority: Build (http://shortn/_oGeGpyBoZ1)

craigb@: This is something to consider as you think about smarter scheduling of tests.

In this case, I propose that dynamic_suite should schedule retries at suite priority + 1, so that retries get ahead of any other suites that are at the same priority as the current suite.
Suites waiting around behind other suites both increase latency of suites and increase instances of timeouts. 
We already limit the total number of retries allowed within a suite, so allowing these retries at a higher priority will ensure that suites act as if the retries were scheduled at the same time as the original tests.

+xixuan: 
This has another positive side-effect.
Currently, dynamic_suite tries to schedule (manually curated) LONG tests before the SHORT ones. But this breaks with retries -- a retried LONG test ends up behind all the already scheduled SHORT ones. If retried tests have a higher priority, they'll get executed before other tests even in the same suite. This means that a retried LONG test will get executed before original SHORT ones. This also means that a retried SHORT test will get executed before original LONG ones, but once again we're protected by the cap on total number of retries allowed across the suite.

The actual implementation should be fairly trivial. Am I missing anything here?

Another instance of this from yesterday: https://cros-goldeneye.corp.google.com/chromeos/healthmonitoring/suiteDetails?suiteId=206025308

 Issue 850196  has been merged into this issue.

#1 sgtm

Does qschedular care / mitigate this problem?
Or is this a test planning fly?

Possible FR for quotascheduler. Low priority