We investigated all 10 E2E failures and determined they are environment-level issues unrelated to the dependency bumps in this PR. The davinci-suites dev server on port 5829 crashes mid-run (mock API unavailable), leaving a zombie process that prevents the journey-suites from binding the same port. A rerun in a clean CI environment should resolve these failures.
chore: [nx migration] update-23-2-0-use-import-meta-dirname
815788b120Open on GitHubSelf-Healing CI
An empty commit was applied to the branch to trigger a new CI pipeline execution to resolve the environment issue.
All 10 failing tasks are Playwright E2E tests — none are unit tests affected by the vitest 4 / undici / fast-uri dependency bumps that this PR introduces.
davinci-suites (6 files): The first test in each file fails because expected UI elements (e.g. "Sign On", "Username/Password Form", "Select Form Fields Test Form") are not rendered within the timeout. This indicates the DaVinci mock API backend is not responding correctly in this CI environment — the dev server on port 5829 starts, but the application cannot complete its flows. After the first test exhausts its timeout or crashes, subsequent tests in the same file receive net::ERR_CONNECTION_REFUSED at localhost:5829, meaning the dev server process has gone away.
journey-suites (4 files): Every journey-suites test fails immediately with Error: http://localhost:5829 is already used. This is a direct consequence of the davinci-suites dev server still holding port 5829 (as a crashed/zombie process) when journey-suites attempts to bind its own dev server to the same port.
Why this is not a code_change: The PR exclusively modifies dependency versions (vitest 3→4, undici, fast-uri) and accompanying migration scaffolding (ESLint flat config, vi.clearAllMocks() fix in one unit test file). None of these changes touch Playwright configuration, dev-server port assignments, the DaVinci mock API, or any E2E test infrastructure. The port conflict between davinci-suites and journey-suites at localhost:5829 is a pre-existing environment configuration issue, not something introduced by this PR.
Flakiness check: The flakiness rate for the sampled tasks is 0%, ruling out a flaky_task classification.
The failures are environment-level: the CI runner's mock API is unavailable and a zombie dev server process blocks the second suite from starting. A clean environment rerun is required.