We investigated the tanstack-react-start-e2e-custom-server-rsbuild:build failure and found it is caused by an internal rspack Rust runtime panic (Dependency with ID DependencyId(1) not found, exit code 134), not by the PR's code changes. Our changes are a functionally equivalent inline refactor and the failing project was not directly modified by this PR. This is a known class of rspack tooling bug that requires an environment-level fix (e.g. rspack/rsbuild version update or cache reset) rather than a code change.
Self-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 tanstack-react-start-e2e-custom-server-rsbuild:build was not classified as a code change for the following reasons:
1. The error is an internal rspack toolchain panic, not a code error. The build output shows a Rust-level runtime panic inside the rspack bundler: Dependency with ID DependencyId(1) not found, terminating with exit code 134 (SIGABRT). This is not a TypeScript/JavaScript compilation error or a test assertion failure — it is the bundler itself crashing due to internal state corruption.
2. The failing project was not touched by the PR. The touched projects are root, @tanstack/react-router, @tanstack/solid-router, and @tanstack/vue-router. The project tanstack-react-start-e2e-custom-server-rsbuild is not among them, meaning no files in that project were directly modified.
3. The code change is functionally equivalent. The PR removes the isCtrlEvent helper function and inlines the condition !(e.metaKey || e.altKey || e.ctrlKey || e.shiftKey) directly. This is a pure refactor with no behavioral difference — there is no logical reason this should cause a build failure.
4. The flakiness rate is 0% and no similar failures exist in other branches. This rules out a flaky test classification and also means this is not a pre-existing widespread issue. However, the absence of similar failures elsewhere does not override the fact that the root cause is clearly an rspack internal bug, not user code.
5. rspack explicitly acknowledges this class of panic as a known tool bug. The panic output itself instructs users to file an issue on the rspack GitHub tracker, indicating this is a recognized category of internal tooling failures that cannot be resolved by changing user code.