We investigated this analog-app-e2e:e2e failure and found no causal link between the PR's changes (Nx upgrade, Oxfmt/Oxlint migration, shipping template rename) and the JSON-LD SSR injection behaviour tested in json-ld.spec.ts:38. The task carries a 10.87% historical flakiness rate, and the consistent failure across retries is consistent with a flaky E2E condition being locked in by the CI environment state rather than a code regression. We recommend rerunning the E2E suite to confirm.
Failed after BSBen SnyderView latest
build(nx-plugin): adopt Nx 23.2 and Oxc workspace tooling
25417cc7d7aOpen 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 failing test (json-ld.spec.ts:38 › JSON-LD › only injects JSON-LD client-side for no-SSR routes) asserts that a raw SSR fetch of the /client route must not contain the string analog-client in the response HTML.
The SSR HTML received in every retry does contain that string — inside a <script type="application/ld+json"> tag — meaning the Analog JSON-LD service is injecting structured data server-side for a route that is supposed to be client-only.
No PR change can be causally linked to this behavior.
The diff was reviewed in full. The only changes to apps/analog-app/ are:
- A template filename rename (
shipping.html→shipping.component.html) in the shipping page component. - A new
.oxlintrc.jsonlinting configuration file.
Neither of these touches the JSON-LD service, the /client route page component, the SSR configuration, or the Vite build config for analog-app. The Nx 23.0.1 → 23.2.0 upgrade, the ESLint flat-config migration, and the Oxfmt/Oxlint tooling changes are all build-tooling concerns and do not alter application runtime behavior in a way that would cause JSON-LD to appear in SSR output for a client-only route.
Historical flakiness confirms non-deterministic behavior.
The analog-app-e2e:e2e task carries a 10.87% flakiness rate, meaning roughly 1-in-9 runs fail without any code change being responsible. This class of E2E test — a raw HTTP fetch checked against SSR output — is sensitive to server startup timing, build-cache state, and worker concurrency, all of which can lock a flaky condition into a consistent-failure mode across retries within a single CI run without a code regression being present.
No similar failures were found on other branches, but this does not override the flakiness signal; it reflects that the flaky condition was triggered in this particular CI environment run rather than indicating that the PR introduced a regression.