I think it sounds like something that would be useful in general. I'd
even go a step further and say that we can replace the current flakey
test mechanism with your proposed solution. If we do that (remove the
current flakey mechanism when this is in place), then I think it would
be super-great as
Chromium's test framework uses the same technique. It has the potential to
really slow things down if you have a lot of failing tests. You might want
some kind of threshold for giving up, I.e. here's 50 failures, I'll stop
running the rest so devs see results sooner.
Otherwise, yeah, this seems re
Note this is similar to the flakey test mechanism, with the primary
difference being that the re-run is done in a minimal CPU load environment
rather than wherever the failure first occurred. The existing flakey test
rerun logic is not helpful for the high-load-induced failures that I'm
looking to
Hi all,
On OS X (and frankly on Linux sometimes as well, but predominently OS X),
we have tests that will sometimes fail when under significant load (e.g.
running the concurrent test suite, exacerbated if we crank up the number of
threads, but bad enough if we run at "number of concurrent workers
