We traced the failing test back to an unrelated part of the codebase and don't believe this PR caused it. The navigate() with href containing basepath test times out on client-side router navigation logic, while this PR only touches server function ID generation in start-client-core and start-plugin-core's babel compiler. Given the 0% flakiness rate rules out a simple flaky rerun, we're classifying this as a pre-existing environment issue rather than something introduced here.
Failed after Ggithub-actions[bot]
ci: Version Packages (#8486)
76938551364Open on GitHubSelf-Healing CI
Classification: Environment state
An empty commit was applied to the branch to trigger a new CI pipeline execution to resolve the environment issue.
The failing task is tanstack-react-start-e2e-custom-basepath:test:e2e, specifically the test "navigate() with href containing basepath" in e2e/react-start/custom-basepath/tests/navigation.spec.ts:79. It times out after 30s on page.waitForURL while waiting for a client-side navigate({ href: '/custom/basepath/posts' }) call (triggered from src/routes/navigate-test.tsx) to resolve to the expected URL.
This PR's actual diff is scoped entirely to server function ID stabilization:
packages/start-client-core/src/createServerFn.ts— adds an optionalidfield to server function options types.packages/start-plugin-core/src/start-compiler/handleCreateServerFn.ts— adds babel AST logic to extract and validate a manual, statically-analyzableidforcreateServerFn.packages/start-plugin-core/src/start-compiler/compiler.ts— addsreserveFunctionId/generateDevFunctionIdand bookkeeping (reservedManualFunctionIdOwners,reservedManualFunctionIdsByFilename) to dedupe and reserve manual/generated server function IDs across recompilations.packages/start-plugin-core/src/start-compiler/host.ts— updatesmergeServerFnsByIdto drop stale IDs when a function's filename/name pair is re-registered under a new ID.- Remaining files are docs, a changeset, and new tests/routes under
e2e/react-start/server-functions(a different e2e app entirely).
None of these changes touch client-side routing, the navigate() API, href/basepath resolution, or anything in router-core. The failing test also lives in a completely separate e2e project (custom-basepath) from the one the PR added tests to (server-functions), and the navigate-test.tsx route and navigation.spec.ts test file are pre-existing and untouched by this diff. touched_projects for this PR is empty, corroborating that no project graph dependency connects the changed packages to this e2e app's navigation behavior.
Checking mcp__utilities__similar_task_failure_outputs for this task ID returned no comparable data from other branches, so a direct "seen elsewhere" match could not be confirmed either way. However, mcp__utilities__task_flakiness_rates reported a 0% flakiness rate for this task, which by the classification rules rules out flaky_task (a 0% rate indicates a deterministic failure rather than intermittent flake) while still not tying it to the PR's code changes. With no line in the diff plausibly causing this navigation timeout, and the failure occurring in an unrelated app/feature area, the most defensible classification is environment_state — a pre-existing/deterministic issue in the test environment or unrelated app code, not something this PR introduced.