Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

useLiveSuspenseQuery never releases over an on-demand collection whose loadSubset returns a Promise

Cerrado
  • ¿Algo no está bien?
#1,858 1 comentario 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
4/5
Tiempo estimado
3-5 días
Aptitud para principiantes
55/100
Tipo de issue
Error
Claridad
Bastante claro
Estado de actividad
Activo
Stack tecnológico
react, typescript
Área
frontend

Línea de trabajo

Start with the useLiveSuspenseQuery implementation and run the supplied @vitest/browser reproduction with npm install && npx vitest run. Compare the synchronous true and Promise-returning loadSubset cases, then verify that an async load suspends once, releases when it resolves, and does not repeatedly recreate the live query.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

Describe the bug

useLiveSuspenseQuery over an on-demand collection never leaves its Suspense fallback whenever loadSubset returns a Promise — which is every real asynchronous data source.

LoadSubsetFn is declared (options) => true | Promise<void>. If an implementation answers with the synchronous true, the boundary releases immediately. If it answers with a promise — even one that resolves on the next tick — the component re-suspends without limit.

To Reproduce

Runnable repro, real Chromium via @vitest/browser: https://gist.github.com/MAST1999/c2261d268a68610f18c5a6c45525b468

npm install && npx vitest run

Plain @tanstack/db. No persistence, no Electric, no orderBy, no limit. The only variable between passing and failing is whether loadSubset returns true or a Promise; both deliver the same two rows.

✓ a synchronous loadSubset releases the boundary                      54ms
× an async loadSubset resolving after   0ms   → text="loading" renders=23525
× an async loadSubset resolving after  50ms   → text="loading" renders=416
× an async loadSubset resolving after 500ms   → text="loading" renders=56
× an explicit queryKey does not change the outcome
× StrictMode is not the cause

Two things a reviewer would reasonably suspect are ruled out in the repro itself: passing an explicit stable queryKey does not help, and it reproduces with StrictMode removed.

The render count falling as the delay grows (23525 → 416 → 56) is the signature of a re-suspend cycle rather than a busy loop — each retry waits for the promise, so a slower promise fits fewer retries into the same five-second budget.

Expected behavior

An async loadSubset should suspend once and release when it resolves.

Likely mechanism

useLiveSuspenseQuery resets promiseRef/hasBeenReadyRef whenever collectionRef.current !== result.collection and throws observer.preload(). A component that suspends before it has ever mounted does not keep its hook state, so each retry constructs a fresh live query, which is loading, which throws a fresh preload promise, which resolves, which retries. The synchronous-true path never suspends at all, which is why it is the only passing case.

I have not confirmed the React-internals half of that (whether a fiber that suspends pre-mount discards its hook state), so treat the mechanism as a hypothesis and the measurements above as the report.

Additional context

This looks like the general case of two issues I filed earlier today, both of which are ways of arriving at a promise-returning loadSubset:

  • #1855 — orderBy + limit makes the ordered loader chain subset requests, so the result is never synchronously ready.
  • #1856 — the SQLite persistence wrapper declares its loadSubset async, so it is a promise even when the wrapped sync answered true.

If this one is fixed, both of those stop being user-visible hangs and become merely redundant work. I'd suggest triaging this first.

Lenguaje dominante
TypeScript
Estrellas
3.9k
Forks
267
Merge medio
1 d 5 h
PR fusionados (30 d)
134

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de TanStack/db

Todos los issues de TanStack/db

Issues similares

Más issues de TypeScript

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.