Failed
Open on GitHub

Merge branch 'main' into stable-serverfn-ids-2 [Self-Healing CI Rerun]

nnx-cloud[bot]
d46600f7
7693Latest execution

Self-Healing CI

Classification: Flaky task

We believe this failure is unrelated to the PR's changes: the failing e2e app has no createServerFn usage at all, so it never exercises the modified server-function-ID compiler logic. The failing assertion checks borderTopColor synchronously right after a route transition, without the same expect.poll(...) retry used one line above for the background-color check in the same test — pointing to test-level flakiness rather than a regression.

An empty commit was automatically applied to the branch to trigger a new CI pipeline execution to resolve the flaky task.

This was not classified as a code_change for the following reasons:

  1. The failing project has no connection to the changed code. The failing task is tanstack-solid-start-e2e-start-manifest:test:e2e, which is not listed in touched_projects. A direct search of that e2e app's source confirmed it contains no createServerFn calls whatsoever, meaning it never invokes the compiler code paths this PR modified (packages/start-plugin-core/src/start-compiler/{compiler,handleCreateServerFn,host,types}.ts).

  2. The PR diff is narrowly scoped. Every changed file in the PR relates exclusively to manual/generated server-function ID reservation, deduplication, and validation. Nothing in the diff touches CSS handling, manifest/chunk generation, or client-side navigation logic — the areas the failing test actually exercises.

  3. The specific failing assertion shows a test-level race, not a logic bug. The test asserts getComputedStyle(element).borderTopColor immediately after a client-side navigation. One line above it, an equivalent background-color check on the same element is wrapped in expect.poll(...) with a timeout/retry, but the border-color check is not. This asymmetry is a strong signal that the border-color assertion can fire before the style has fully applied post-navigation — a timing issue intrinsic to the test itself.

  4. Supporting signals. The similar-task-failure-detector found no matching failure on the reference branch (8268), and the task carries a nonzero measured flakiness rate (~9.3%). Neither of these alone proves flakiness, but combined with the complete absence of a code path connecting the change to the failure, they support a flaky_task classification over code_change.

No code changes are proposed since the failure does not trace back to anything altered in this PR.