useSyncExternalStore loops during hydration when getServerSnapshot differs from getSnapshot (flushPending exceeded 50 iterations)
Maintainer antworten meist innerhalb von 1 Tag
Dieses Issue hat noch niemand übernommen.
Bewertung
- Schwierigkeit
- 4/5
- Geschätzter Aufwand
- 3-5 Tage
- Anfängerfreundlichkeit
- 48/100
- Issue-Typ
- Bug
- Klarheit
- Größtenteils klar
- Aktivitätsstatus
- Aktiv
- Tech-Stack
- react, typescript, vite
Rechercherichtung
Start with packages/redact/src/dom/dispatcher.ts around the cited lines 331–348 and trace how hydration state affects useSyncExternalStore snapshots and scheduled updates. Compare the reproduction's Redact and React runs, then inspect nearby hydration tests or add a focused regression case. Done means hydration settles without the iteration error and reaches the client snapshot, matching React's two renders.
Vom Indexierungsmodell aus dem Issue-Text verfasst.
Beschreibung
🤖 Issue drafted with Claude Code. Reproduced and verified before posting.
Version: @tanstack/redact 0.2.1 (also 0.2.0). Baseline: react/react-dom 19.3.1.
Hydrating a component whose getServerSnapshot differs from getSnapshot never settles: Redact re-renders it 50 times, then hydrateRoot throws flushPending exceeded 50 iterations — suspected infinite update loop. (a bare Error in production). React renders it twice.
This is the "still hydrating?" idiom used by Headless UI 2.x (useServerHandoffComplete, behind Popover, Dialog, Transition…), so any page with a Headless UI component hits it.
Reproduction
npm i @tanstack/[email protected] react@19 react-dom@19 jsdom, then node repro.mjs redact / node repro.mjs react:
// repro.mjs
import { JSDOM } from "jsdom"
const { window } = new JSDOM("<!doctype html><div id=root></div>")
Object.assign(globalThis, { window, document: window.document, HTMLElement: window.HTMLElement, Node: window.Node })
const redact = process.argv[2] === "redact"
const R = await import(redact ? "@tanstack/redact" : "react")
const { renderToString } = await import(redact ? "@tanstack/redact/server" : "react-dom/server")
const { hydrateRoot } = await import(redact ? "@tanstack/redact/dom-client" : "react-dom/client")
let renders = 0
function App() {
const isServer = R.useSyncExternalStore(() => () => {}, () => false, () => true)
renders++
return R.createElement("p", null, isServer ? "server" : "client")
}
const root = document.getElementById("root")
root.innerHTML = renderToString(R.createElement(App))
renders = 0
try {
hydrateRoot(root, R.createElement(App))
} catch (error) {
console.log("hydrateRoot threw:", error.message || "Error")
}
setTimeout(() => console.log({ renders, text: root.textContent }), 100)
| Renders | hydrateRoot throws |
Final text | |
|---|---|---|---|
| React 19.3.1 | 2 | no | client |
| Redact 0.2.1 | 52 | yes | client |
Same result in Chromium with a Vite build (redact() plugin, Redact on server and client).
Likely cause
In dispatcher.ts#L331-L348, the render reads getServerSnapshot() while root.h is set. The effect's check() compares it with getSnapshot(), finds a difference and calls scheduleUpdate. That update is flushed while the root is still marked as hydrating, so it reads the server snapshot again, and check() runs again (the inline subscribe changes every render). Logging inside the loop shows rendered=true client=false hydrating=true at every iteration.
React switches to getSnapshot() once the hydration render has committed, so its second render reads the client value and stops.
Impact
On a TanStack Start storefront using a Headless UI Popover, this adds ~150 ms of main-thread work per page load (4× CPU throttling) and reports an uncaught error, though the page ends up interactive.
- Vorherrschende Sprache
- TypeScript
- Sterne
- 537
- Forks
- 22
- Ø Merge
- 10 Std. 27 Min.
- Gemergte PRs (30 T.)
- 40
Entwicklungsumgebung
Dieses Projekt bietet weder Dev-Container noch Dockerfile noch Beitragsleitfaden – die Einrichtung liegt bei Ihnen. Beginnen Sie mit der README; die allgemeinen Schritte stehen in unserem Leitfaden für den ersten Beitrag.
Erste Schritte
- Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
- Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
- Forken Sie das Repository und arbeiten Sie in einem Branch.
- Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.
Mehr aus TanStack/redact
-
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 84/100
TanStack/redact#142 · 4 Kommentare ·
Maintainer antworten meist innerhalb von 1 Tag
-
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 85/100
Maintainer antworten meist innerhalb von 1 Tag
-
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 78/100
Maintainer antworten meist innerhalb von 1 Tag
-
Schwierigkeit 3/5 1-2 Tage Anfängerfreundlichkeit 55/100
TanStack/redact#164 · 1 Kommentar ·
Maintainer antworten meist innerhalb von 1 Tag
-
Schwierigkeit 4/5 3-5 Tage Anfängerfreundlichkeit 49/100
Maintainer antworten meist innerhalb von 1 Tag
Alle Issues in TanStack/redact
Ähnliche Issues
-
The sample email preview's ResizeObserver is never disconnected and keeps raising errors after leaving SettingsEvtl. vergeben Ein verknüpfter Pull Request ist offen oder bereits gemergt. Offenbug
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 82/100
Maintainer antworten meist innerhalb von 1 Tag
-
area:ui bug effort:S priority:P2
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 72/100
Maintainer antworten meist innerhalb von 1 Tag
-
Typo in WSL project description on Projects pageEvtl. vergeben @akhil9tiet hat das heute übernommen. Offen
Schwierigkeit 1/5 Unter einer Stunde Anfängerfreundlichkeit 75/100
microsoft/opensource.microsoft.com#1066 · 1 Kommentar ·
-
ArcGIS Maps SDK for JavaScript c-carousel calcite-design-tokens enhancement impact - p3 - not time sensitive needs triage
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 68/100
Esri/calcite-design-system#15565 ·
Maintainer antworten meist innerhalb von 1 Tag
-
bug
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 68/100
linkwarden/linkwarden#1891 ·
Maintainer antworten meist innerhalb von 1 Tag