We classified this E2E failure as flaky rather than a regression introduced by the undici upgrade. The test has an 18% historical flakiness rate and the error — a 5000ms DOM visibility timeout on the "Registration Complete" heading — has no direct causal link to HTTP client behaviour changes. Rerunning the suite should resolve it.
Failed after
Rrenovate[bot]View latestchore(deps): update dependency undici to v8
8064b9ec19Open on GitHubSelf-Healing CI
Classification: Flaky task
An empty commit was automatically applied to the branch to trigger a new CI pipeline execution to resolve the flaky task.
The AI model provider was experiencing issues when this fix was generated.
The failing task @forgerock/davinci-suites:e2e-ci--src/phone-number-field.test.ts was classified as a flaky task rather than a code change for the following reasons:
Error type is a UI timing issue, not an API regression. The test fails because the "Registration Complete" heading is not visible within a 5000ms timeout. This is a classic non-deterministic E2E failure — the element may simply not have rendered in time — and bears no logical connection to the undici HTTP client upgrade.
High historical flakiness rate. This task has an 18.06% flakiness rate, meaning it has a well-established history of intermittent failures independent of code changes.
The lockfile-driven
touched_projects: ["*"]does not indicate code relevance. The*in touched_projects comes from the undici lockfile bump, not from any modification to thedavinci-suitese2e test files or the application code they exercise. The*wildcard therefore does not signal that the PR change is causally related to this test's failure.Failure is absent in the comparison branch. The similar-task-failure detector found no matching failure in branch 802, ruling out a pre-existing environment or configuration issue shared across branches.
No direct code path connects undici v8 to this failure. Even if undici's HTTP behaviour changed, the assertion is on a DOM heading element — any undici-related latency or behavioural change would have to propagate through the entire request/response/render pipeline to cause a 5000ms DOM timeout, with no evidence that this occurred deterministically.