Flaky: async/timer_regress22626_test appears flaky by design

[kasperl]

The test case looks flaky and it is (very rarely) causing issues on the build bots. Contrary to the original status file update by @whesse this doesn't appear to happen only on MIPS.

[kasperl]

Added area-vm because the regression test case was added as part of fixing a VM issue.

[mraleph]

This issue has been open for 315 days. Please consider investigating whether it is still meaningful and if not close it. If the issue is still meaningful please find a relevant owner. Thank you.

[mraleph]

Should we delete the test and close this issue?

[dcharkes]

It looks like the test it not always disabled and we are still running it in $mode = release && $compiler == dartkb.

All status files together:

[ $mode == debug && $hot_reload_rollback && ($compiler == dartk || $compiler == dartkb) ]
async/timer_regress22626_test: Skip # Timing dependent

[ $compiler == app_jit || $compiler == none || $compiler == precompiler ]
...
async/timer_regress22626_test: Pass, RuntimeError # Issue 28254

[ $hot_reload ]
...
async/timer_regress22626_test: Pass, RuntimeError # Timing dependent.

[ $compiler == dart2js && $runtime == jsshell ]
...
async/timer_regress22626_test: RuntimeError # Non-zero timers not supported; Issue 7728.

(Note that #7728 was solved already but the status entry was not deleted.)

@mraleph: should I go ahead and create a CL to delete this test?

[whesse]

Looking at the original issue, that this is a regression test for (#22626), the issue was diagnosed and fixed, and this regression seems so specific that we don't lose much coverage by dropping this test. On the other hand, if the timeout of 200ms in "test(200, 2)" is increased to 2s or more, it should be a passing, never flaky test and could be run everywhere. So a CL dropping it seems ok to me.