We investigated the analog-app-e2e:e2e failure and confirmed it is a pre-existing defect in the ssr: false route-policy on the base alpha branch — the PR author explicitly notes the identical assertion fails on untouched alpha and that a dedicated fix is tracked in analogjs/analog#2523. No files from the analog-app-e2e project were modified by this PR, and the failure reproduces deterministically with the same error across all retries, ruling out flakiness. No changes to this PR are required to address it.
fix(vite-plugin-angular): preserve server mode in environment builds
25203e0d047Open on GitHubSelf-Healing CI
An empty commit was applied to the branch to trigger a new CI pipeline execution to resolve the environment issue.
The failing test is tests/json-ld.spec.ts:38:7 › JSON-LD › only injects JSON-LD client-side for no-SSR routes in the analog-app-e2e:e2e task.
The assertion at line 45 fails deterministically across all three retry attempts with the same error: the SSR response for the /client route (which is configured as ssr: false) unexpectedly includes a JSON-LD script bearing identifier: "analog-client". This is not a timing or race condition — it is a consistent behavioral failure.
The analog-app-e2e project does not appear in touched_projects (which is []), meaning no files belonging to this E2E project were modified by this PR.
Most critically, the PR author explicitly acknowledges this failure in the PR body:
"After the bootstrap repair, main CI reaches E2E and is blocked by the existing
ssr: falseroute-policy defect. The identical raw-response assertion fails on untouched alpha."
This confirms the defect is pre-existing on the base alpha branch and is not a regression introduced by this PR. The author further states that a separate prerequisite PR (analogjs/analog#2523, tracking platform issue analogjs/analog#2522) is being prepared specifically to repair this route-policy defect.
Because the failure pre-dates this PR, is reproducible on untouched alpha, is not caused by any file changed in this diff, and has a dedicated fix tracked elsewhere, it cannot be classified as a code_change for this PR.