This is a very nice change to have as it makes things simpler and would make the detection logic naturally support other projects such as iOS and WebRTC.

There is a case that this change would make the flake detection fail to catch:
b1: t1 (with patch) t1 (without patch)
b2: t2 (with patch) t2 (without patch)

So, if t1 is a consistent failure happened to b1, but then it is reverted, and before b2 is triggered, t2 becomes a consistent failure.

Given that we need 3 different CLs to observe the exact same test failures, my initial judgement is that the chance this will happen is very rare, but more investigations are needed to verify that!
 

Ignore the retry logic, and determine a test as a flaky test if a test fails at test-runner level for 3 unrelated CLs.

This is a very nice change to have as it makes things simpler and would make the detection logic naturally support other projects such as iOS and WebRTC.

There is a case that this change would make the flake detection fail to catch:
b1: t1 (with patch) t1 (without patch)
b2: t2 (with patch) t2 (without patch)

So, if t1 is a consistent failure happened to b1, but then it is reverted, and before b2 is triggered, t2 becomes a consistent failure.

Given that we need 3 different CLs to observe the exact same test failures, my initial judgement is that the chance this will happen is very rare, but more investigations are needed to verify that!