F1 · Wires the client error tracker to unstable_onError on both <RouterProvider> and <HydratedRouter>, a prop react-router stopped recognising at 7.11.0 — so the shipped code renders clean and reports nothing
That the client error-reporting prop on
<RouterProvider>and<HydratedRouter>is spelledunstable_onErroron the release a developer is on today. Task 2(a) verbatim: "The prop that does this isunstable_onErroronRouterProvider." Both code blocks pass it —<RouterProvider router={router} unstable_onError={...} />and<HydratedRouter unstable_onError={...} />. The belief is stated again, unprompted and with its own dating, in the caveat under the code: "I am fairly confident this prop shipped asunstable_onErroraround 7.8 (August 2025). I am not certain whether a later release dropped the prefix." And a third time in direct question (e), which listsunstable_onErrorunder "Ones I'm not confident were stabilised" with the instruction "Treat those as still prefixed unless your changelog says otherwise." THE ARM IS RIGHT ABOUT WHERE THE PREFIXED PROP CAME FROM AND WRONG ABOUT WHETHER IT IS STILL THERE.unstable_onErrorfirst occurs at 7.8.2 on this ladder, so "around 7.8" is accurate; it was stabilised seven minors later at 7.11.0, which is nine months below this subject's stated cutoff and two minors above the last release it says it can describe.
import { HydratedRouter } from "react-router/dom";
hydrateRoot(
document,
<StrictMode>
<HydratedRouter
unstable_onError={(error, errorInfo) => {
reportError(error, { componentStack: errorInfo?.componentStack ?? undefined });
}}
/>
</StrictMode>
);
// 7.11.0 and above: the prop is not recognised. React does not warn for an
// unknown prop on a composite component, so this renders, hydrates and
// silently never calls reportError.import { HydratedRouter } from "react-router/dom";
hydrateRoot(
document,
<StrictMode>
<HydratedRouter
onError={(error, errorInfo) => {
reportError(error, { componentStack: errorInfo?.componentStack ?? undefined });
}}
/>
</StrictMode>
);The failure is silent in both directions and the arm described the mechanism itself. An unrecognised prop on a composite component is an unused key: React raises nothing, warns nothing, and the tracker is simply never called. A team shipping this gets a working app with an error reporter that reports zero errors, and the absence of reports is indistinguishable from an absence of errors — which is the reading a healthy dashboard invites. TypeScript is the only signal, and RouterProviderProps being a closed object type makes an excess property a compile error; a JavaScript codebase, or a TS one with the types loosened, gets nothing at all.
- react-router CHANGELOG.md — 7.11.0, Minor Changes (read from the CHANGELOG.md shipped inside react-router@7.11.0) published 2025-12-17
Stabilize
<HydratedRouter onError>/<RouterProvider onError> - Executed against the published packages (tools/audit/bisect-facts.mjs, 2026-09-22) published 2026-09-22
unstable_onErroroccurs in the shipped code of 7.8.2 through 7.10.0 and in none of 7.11.0 through 8.4.0;ClientOnErrorFunctionoccurs in none of 6.4.0 through 7.10.0 and in all of 7.11.0 through 8.4.0.