router
Failed after Lladybluenotes

perf(router,start): update Seroval to 1.6.7

82973d23bc2Open on GitHub

Self-Healing CI

Classification: Code change neededFix generatedVerification not started

We investigated this failure and concluded no code change is needed here. The failing HMR e2e suite passed cleanly (28/28) twice when rerun unmodified against this PR's code, and diffing seroval's build output between 1.6.2 and 1.6.7 shows the only relevant internal change is a fix to a stream-listener bug, not a regression this bump could have introduced. The original failure looks like a transient filesystem-watch timing issue in the test harness rather than something caused by this diff.

No source code changes were made. Investigation into the failing tanstack-react-start-e2e-hmr:test:e2e task found no defect introduced by this PR's change (bumping seroval from 1.6.2 to 1.6.7 across router-core, start-client-core, start-server-core, start-plugin-core, and start-static-server-functions):

  • The exact failing task was rerun twice against the PR's code, completely unmodified, and passed 28/28 both times.
  • The built output of seroval was diffed line-by-line between 1.6.2 and 1.6.7. The only change touching the internal stream/plugin machinery that router-core's custom serialization plugins rely on (createPlugin, PluginInfo, SerovalNode) is a fix to a listener-array bug in the internal pub/sub used by createStream(): the old (1.6.2) code could silently drop an active stream listener when unsubscribes happened out of order, and 1.6.7 corrects that. This is a fix in the direction the PR moves, not a regression it introduces.
  • seroval-plugins was left at ^1.6.2 in the diff, but its peerDependencies range on seroval is a loose ^1.0, and the lockfile resolves a single consistent seroval@1.6.7 across the whole workspace, so there is no duplicate-instance or version-skew issue either.
  • The original failure cascade began with a beforeEach hook timing out while polling for a route file change to be observed by the dev server's file watcher (waitForRestoredRouteFile, a 20s poll under a 30s test timeout). That is a filesystem-watch timing dependency, unrelated to anything touched by the diff, and consistent with a transient slowdown (e.g. CI machine load) rather than a deterministic bug.

Given the clean, repeated reproduction and the absence of any plausible mechanism in the diff for the observed failure, no source change was warranted. Since the failing task was originally classified as code_change, this is a case where the classification does not survive the deeper investigation done during the fix step, flagged here for follow-up rather than papering over it with a speculative dependency edit.