We traced all 14 failing e2e tasks to the same deterministic assertion in special-characters.spec.ts (expected HTTP 400, got 404) for malformed percent-encoded paths, reproduced identically across react-start, vue-start, and solid-start under every bundler/mode combination. Since none of these e2e packages depend on the removed @tanstack/nitro-v2-vite-plugin, and the failure shows 0% flakiness with perfectly uniform reproduction, we don't believe this PR introduced it — no code changes are proposed here.
Self-Healing CI
Classification: Environment state
No code changes are applicable.
This was not classified as a code change for the following reasons:
The PR's diff is narrowly scoped and doesn't touch the affected code path. The changes only remove the unused @tanstack/nitro-v2-vite-plugin package (its package.json, src/index.ts, config files, README/CHANGELOG), drop its pnpm-workspace.yaml override and labeler-config.yml entry, regenerate the lockfile, and tweak wording in the hosting guide. No router, server, or start-core packages are touched.
The failing packages don't depend on the removed code at all. Inspection of the affected packages' package.json files (e.g. e2e/react-start/basic/package.json) confirms none of them depend on @tanstack/nitro-v2-vite-plugin or nitropack. They use Express/srvx-based dev servers, vite, and rsbuild directly. There is no plausible mechanism by which removing this package could affect their behavior.
The failure pattern is uniform and deterministic, not a targeted regression. All 14 failing tasks (across react-start, vue-start, and solid-start, spanning vite-ssr, vite-preview, vite-prerender, rsbuild-ssr, rsbuild-ssr--iife, and rsbuild-prerender variants) fail with the identical error signature: expect(received).toBe(expected) // Expected: 400, Received: 404, from the same "Unicode route rendering › malformed paths" test block. Each task shows exactly 3 failed tests corresponding to the three malformed pathname variants tested. This kind of uniform, cross-framework, cross-bundler failure is inconsistent with a regression caused by a narrowly-scoped, single-package removal — it looks like a pre-existing issue in shared URL-decoding behavior.
Flakiness data supports a deterministic, pre-existing issue rather than a new regression. mcp__utilities__task_flakiness_rates returned 0% flakiness for the sampled tasks, and the failure reproduced consistently rather than intermittently, ruling out a flaky_task classification.
Cross-branch comparison was inconclusive, not contradictory. The similar-task-failure-detector subagent checked branch 8535 for a matching signature but got back an empty result set (no recorded output for these task IDs on that branch). This didn't confirm the failure pre-exists there, but it also didn't contradict that theory — it's simply missing data rather than evidence against the classification.
Taken together, the evidence points to a pre-existing test/environment issue unrelated to this PR's scope, so per guidance, no fix was proposed within this PR.