Status Update
No update yet.
Comments
el...@google.com
This bug has led to a large number of gardened builds failing in the last 7 days. List of gardened build failures caused by this cluster can be viewed at:
or in LUCI Analysis and grouped by builders:
Please consider the following strategies to mitigate the impact from this issue which are rated in order of resolution preference:
1. Resolve the underlying test issue.
2. Move the flaky test from Critical Builders to FYI Builder
3. Disable test (least desirable as it reduces test coverage) and add a Test-Disabled label to this issue. The disabled tests might continue running in reviver builders (go/test-reviver), see config [1] for a list of supported builders.
When investigating this failure, you may identify this bug is too broad (encompasses multiple different issues) or too narrow (only captures one part of a larger issue). If this applies, you can combine issues[2] or split issues[3].
Links:
[1]
[2]
[3]
Why LUCI Analysis posted this comment:
el...@google.com
as...@chromium.org
I clicked through and maybe we're hitting this issue in the test assertions?
per the output here:
Which sounds like the issue might be in the DWA code being tested?
it...@google.com
The logs from the CAS output(04:28.136 Immediately halt execution of testcase - ((([MetricsAppInterface DWARecorderHasEntries:__objc_no])) is true) failed DWA Recorder should not have any entries.
being the last thing to fail.
The first failure came from:
00:22.079 Immediately halt execution of testcase - matched is false: Failed waiting for element with matcher ((respondsToSelector(accessibilityIdentifier) && accessibilityID('betterSearchAndBrowsingItem_switch')) && tableViewSwitchToggledState(ON) && tableViewSwitchEnabledState(YES) && sufficientlyVisible(Expected: 0.750000, Actual: 0.000000)) to appear
Basically, the test fails to open the "Google Services" settings sub-menu, or doesn't open it in time to toggle that switch before the asserts run.
Resolved bug by adding some additional waits and linked CL on the bug so marking as resolved.
ap...@google.com
Project: chromium/src
Branch: main
Author: Ruth Itua <
Link:
[Fix] Flaky DWATestCase/testUkmMsbbConsentChangeCheck
Expand for full commit details
[Fix] Flaky DWATestCase/testUkmMsbbConsentChangeCheck
NO_IFTTT=for dwa_egtest, as only fixing flaky test.
Bug: 400413009
Change-Id: I0bf3566ffd01f4c8f6e520d5f7be148ec2bd5e26
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6331138
Reviewed-by: Olivier Robin <olivierrobin@chromium.org>
Reviewed-by: David Roger <droger@chromium.org>
Commit-Queue: Ruth Itua <itua@google.com>
Cr-Commit-Position: refs/heads/main@{#1428951}
Files:
- M
ios/chrome/browser/metrics/model/dwa_egtest.mm
Hash: 6a8b8d95fcc0382870bcc8daa10dab34465a5939
Date: Thu Mar 06 08:25:34 2025
Description
DWATestCase/testUkmMsbbConsentChangeCheck is flaky on iPad Air (5th generation and 6th generation) which causes the ios-simulator-full-configs check to fail
Latest Simulator failure:https://ci.chromium.org/ui/p/chromium/builders/try/ios-simulator-full-configs/148931/overview
Change-Id:https://chromium-review.googlesource.com/c/chromium/src/+/6225859
Unable to reproduce error locally as swarming link returns SUCCESS(https://chromium-swarm.appspot.com/task?id=6f66e82ee2c39810 ) and repeated runs of flaky tests on same iOS version simulators passes locally on XCode.