rc.14: an effect that catches NotReadyError from an async store is never re-run when the store settles
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
- 25/100
- Tipo de issue
- Error
- Claridad
- Bien especificado
- Estado de actividad
- Activo
- Stack tecnológico
- javascript, typescript
- Área
- frontend
Línea de trabajo
Start with the headless repro.mjs in the issue, which pins @solidjs/signals to 2.0.0-rc.13 and then rc.15 to compare effect re-runs. The payload names no source files, so locate where NotReadyError is thrown for async store derives and where an effect is scheduled to re-run when that derive settles. Done means the effect with try/catch records ["not-ready","len=1"] again on the current version, matching rc.13, and the without-try/catch case still passes.
Escrito por el modelo de indexación a partir del texto del issue.
Descripción
Summary
@solidjs/[email protected] and rc.15 (dev and prod builds). Regression since rc.13.
An effect whose compute reads an async-seeded store (createStore(async fn, [])) and catches the NotReadyError that read throws runs once with its fallback value and is never re-run when the store's seed settles. The store itself settles: an untracked read afterwards returns the data. The same effect without the try/catch holds and then runs once with the settled value, as before. An async createMemo read the same way is still re-run on rc.15, so this looks specific to async store derives.
const [rows] = createStore(async () => await request, []);
createEffect(
() => { try { return `len=${rows.length}`; } catch { return "not-ready"; } },
(v) => seen.push(v),
);
// rc.13: ["not-ready", "len=1"] rc.14 / rc.15: ["not-ready"], forever
Reproduction (headless, only @solidjs/signals)
mkdir solid-catch-notready && cd solid-catch-notready
npm init -y >/dev/null && npm pkg set type=module && npm i @solidjs/[email protected] >/dev/null
cat > repro.mjs <<'JS'
// An effect whose compute catches NotReadyError from an async-seeded store
// is re-run when the seed settles (rc.13) — or never again (rc.14, rc.15).
import { createEffect, createRoot, createStore, flush } from "@solidjs/signals";
const tick = (ms) => new Promise((r) => setTimeout(r, ms));
for (const caught of [false, true]) {
let resolve;
const request = new Promise((r) => (resolve = r));
const seen = [];
const dispose = createRoot((dispose) => {
const [rows] = createStore(async () => await request, []);
createEffect(
() => {
if (!caught) return `len=${rows.length}`;
try { return `len=${rows.length}`; } catch { return "not-ready"; }
},
(v) => { seen.push(v); },
);
return dispose;
});
flush();
resolve([{ id: "a" }]);
await tick(10);
flush();
console.log(`${caught ? "with try/catch " : "without try/catch"}: ${JSON.stringify(seen)}`);
dispose();
}
JS
node repro.mjs
@solidjs/signals |
without try/catch | with try/catch |
|---|---|---|
| 2.0.0-rc.13 | ["len=1"] |
["not-ready","len=1"] |
| 2.0.0-rc.14 | ["len=1"] |
["not-ready"] |
| 2.0.0-rc.15 | ["len=1"] |
["not-ready"] |
Replacing the store with const memo = createMemo(async () => await request) (reading memo().length) gives ["not-ready","len=1"] on rc.15.
(Pin @solidjs/signals directly: npm i [email protected] alone installs the newest signals through its caret dependency.)
Where we hit it
@dschz/solid-flow pins its async store factories (createNodeStore(async () => …), a thin wrapper over createStore(fn, [])) with this exact effect, which records "not-ready" until the first value and then the row count. Two of its tests fail on rc.14 and rc.15. The library itself never catches NotReadyError, so for us this is a test idiom, but a user's effect that degrades gracefully while data loads would stay on its fallback forever.
If catching NotReadyError in a compute is not a supported pattern, a dev diagnostic for it would help: today the effect silently never updates.
- Lenguaje dominante
- TypeScript
- Estrellas
- 36.1k
- Forks
- 1.1k
- Merge medio
- 11 h 49 min
- PR fusionados (30 d)
- 346
Preparar el entorno
- Sin Dockerfile ni archivo de Docker Compose
- Tiene una plantilla de pull request
- Leer la guía de contribución
Primeros pasos
- Lee el issue completo y luego la guía de contribución del proyecto.
- Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
- Haz un fork del repositorio y trabaja en una rama.
- Abre un pull request que haga referencia al número del issue.
Más de solidjs/solid
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 62/100
Los mantenedores suelen responder en 1 día
-
Dificultad 4/5 3-5 días Aptitud para principiantes 18/100
Los mantenedores suelen responder en 1 día
-
Dificultad 3/5 Medio día Aptitud para principiantes 55/100
Los mantenedores suelen responder en 1 día
-
[2.0 / next] Error formatting and async iterator protocol failures escape memo error handlingAbierto
Dificultad 4/5 3-5 días Aptitud para principiantes 22/100
Los mantenedores suelen responder en 1 día
-
Dificultad 5/5 Más de una semana Aptitud para principiantes 14/100
Los mantenedores suelen responder en 1 día
Todos los issues de solidjs/solid
Issues similares
-
Dificultad 1/5 Menos de una hora Aptitud para principiantes 83/100
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 72/100
ranxianglei/billion-context#3583 ·
Los mantenedores suelen responder en 1 día
-
bug:new
Dificultad 2/5 1-3 horas Aptitud para principiantes 76/100
callstackincubator/simlock#673 ·
Los mantenedores suelen responder en 1 día
-
documentation v3
Dificultad 2/5 1-3 horas Aptitud para principiantes 73/100
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 73/100
anomalyco/opencode#56380 · 1 comentario ·
Los mantenedores suelen responder en 1 día