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

[2.0 / next] Reading a pending getter in equals leaves the UI stuck

Abierto
  • ¿Algo no está bien?
#4,111 0 comentarios 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
5/5
Tiempo estimado
Más de una semana
Aptitud para principiantes
14/100
Tipo de issue
Error
Claridad
Bastante claro
Estado de actividad
Activo
Stack tecnológico
javascript, typescript
Área
frontend

Línea de trabajo

Start in packages/signals/src/core/core.ts around the synchronous comparator catch, and in packages/signals/src/core/async.ts around the async settlement catch and the shared handleError path. Both catches call notifyStatus(el, STATUS_ERROR, e) on NotReadyError, so pending reads are treated as terminal. Reproduce with the linked pending-getter playground, then check the cleanup regression in PR #3886. Done means the getter reaches Value: 2 and the cleanup test passes, which needs maintainer input on how suspension inside equals should behave.

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

Descripción

Describe the bug

A memo returns an object with a getter that reads an async memo. Reading the getter during rendering works with <Loading>, but reading it in equals produces an uncaught NotReadyError. The async work then resolves, yet the UI stays on the previous value.

Removing the custom comparator lets the same getter render the resolved value.

Your Example Website or App

https://s.olid.uk/id/-g2RtrPeRk-xTEPedugSCg

Steps to Reproduce the Bug or Issue
  1. Open the playground and wait for Value: 0.
  2. Click Run demo. The comparator reads the new object's getter while its async memo is unresolved. The console reports NotReadyError.
  3. After one second, the console logs Resolved: 2, but the UI remains at Value: 0.

Control: remove the equals option and rebuild. Repeat the steps: the UI reaches Value: 2 without the error.

Expected behavior

A pending read through the getter should be handled by <Loading> and allow the UI to reach Value: 2 once the async work resolves. If reads that suspend are unsupported inside equals, a clear diagnostic would be preferable to an uncaught control-flow error that leaves updates halted.

Screenshots or Videos

No response

Platform
  • OS: Linux
  • Browser: Chromium 154.0.8037.57
  • Solid: playground pinned to next@d5e32a9af41c7bfe0bc090f7438ee4297d540b17. The comparator catches discussed below are also present on current next@ccd99481deed3ebb567ee11ab7a152ced84d122b.
Additional context

The comparator catches in synchronous recomputation and async settlement both unconditionally call notifyStatus(el, STATUS_ERROR, e). That appears to classify a pending read as a terminal error. Comparator reads also run outside the memo's tracking context, so classifying NotReadyError as pending alone would not establish the dependency needed to retry.

The async catch additionally bypasses the existing shared error handler, which handles promise rejections and errors from the async setter. A candidate change from #3886 is:

 } catch (e) {
-  notifyStatus(el, STATUS_ERROR, e);
+  handleError(e);
 }

That change fixes a separate cleanup omission: if a lazy dependent loses its last consumer while the async source is pending, and the source's comparator throws on fulfillment, the dependent is left subscribed and its cleanup never runs. Cleanup playground: click Run demo and inspect Cleanup calls: 0; ordinary fulfillment and direct promise rejection each produce 1 in the same setup. The memo's owner stays alive; only its rendered consumer is removed.

Routing the async catch through handleError makes that cleanup regression pass, along with the existing comparator-error and pending-disposal tests. Non-lazy cleanup still waits for owner disposal in the tested case. However, this change alone does not make the pending-getter example recover: the async version instead reports an untracked-read diagnostic. The synchronous comparator catch and the intended handling of suspension inside comparators need consideration too.

#3886 contains the candidate async-handler change and cleanup regressions. That comparator-release case was outside #4085's held-error scope.

Lenguaje dominante
TypeScript
Estrellas
36.1k
Forks
1.1k
Merge medio
11 h 49 min
PR fusionados (30 d)
346

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 solidjs/solid

Todos los issues de solidjs/solid

Issues similares

Más issues de TypeScript

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.