Example build:
https://ci.chromium.org/p/chromium/builders/luci.chromium.ci/Linux%20Chromium%20OS%20ASan%20LSan%20Tests%20%281%29/30969

Could it because the test runs too slowly under msan/asan? Many tests in the same file are tagged with TEST_DISABLED_ON_MSAN.

And this test seems spending about 60+ seconds to finish loading enrollment screen assets (Note the timestamp 115042 -> 115144).

Snippet of log:
====
[ RUN      ] EnterpriseEnrollmentConfigurationTest.TestEnrollUsingToken
HTTPS server started on 127.0.0.1:33442...
sending server_data: {"host": "127.0.0.1", "port": 33442} (36 bytes)
[26190:26190:0108/115042.471449:ERROR:child_process_security_policy_impl.cc(1277)] Ignoring port number in isolated origin: https://accounts.google.com:33442
...
[26190:26190:0108/115144.669379:INFO:CONSOLE(9945)] "Finished loading asset bundle oauth-enrollment", source: chrome://oobe/oobe.js (9945)

looks familiar, as I changed the waiting logic of that test code indeed (https://chromium-review.googlesource.com/c/chromium/src/+/1391739).

Maybe my patch wasn't enough?

The flakiness dashboard shows this just started being flaky. The link above for regression range is the first failure I saw. So, I don't think it's Jun's patch. 

sky@: is the flake on CQ or CI?

The new flake detector seems not to catch this test on CQ https://findit-for-me.appspot.com/flake/occurrences?key=ag9zfmZpbmRpdC1mb3ItbWVyXAsSBUZsYWtlIlFjaHJvbWl1bUBicm93c2VyX3Rlc3RzQEVudGVycHJpc2VFbnJvbGxtZW50Q29uZmlndXJhdGlvblRlc3QuVGVzdEVucm9sbFVzaW5nVG9rZW4M

If it is on CQ, we will dig into why this is not caught.

Main waterfall.

Here's the link I was looking at: https://test-results.appspot.com/dashboards/flakiness_dashboard.html#testType=browser_tests&tests=EnterpriseEnrollmentConfigurationTest.TestEnrollUsingToken . The test failed twice on the ASAN bot in a row, and hasn't failed since. Maybe something bad landed and was reverted? Or something bad landed as was fixed? No idea.