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

2.0: grouping isPending(x) with x() in one effect changes which lanes a later write opens

Cerrado
  • ¿Algo no está bien?
#4,398 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
45/100
Tipo de issue
Error
Claridad
Bastante claro
Estado de actividad
Activo
Stack tecnológico
javascript, typescript
Área
frontend

Línea de trabajo

Start with the failing test pin verdict-memo-flight-no-reask.test.ts mentioned in the issue, then compare the grouped and split cases in review-4397/zz-grouping.test.ts and the probe results in probe-h-wip.txt. Trace how isPending(m1) and m1() participate in an open transaction when the later setT(1) runs. Done means a test establishes the intended behavior from the #4284 ruling and JSX grouping no longer changes which lane questions m1 asks.

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

Descripción

What happens

An async memo m1 reads two verdict memos:

const m0  = createMemo(() => ask("m0",  1 + latest(s) + s()));
const m0b = createMemo(() => ask("m0b", 10 * (latest(t) + t())));
const m1  = createMemo(() => ask("m1",  1 + m0() + m0b()));
// under a Loading boundary
setS(2); /* 12 ms later */ setT(1);

With #4397, m1 asks each question once, but which questions it asks depends on how the readers are grouped:

  • Grouped, one render effect reading ${isPending(m1)},${m1()}: m0:4, m1:5, m0b:10, m0b:20, m0:5, m1:26
  • Split, one effect reading isPending(m1) and another reading m1(): m0:4, m1:5, m0b:10, m0:5, m1:15, m1:16, m0b:20, m1:26

The final value is the same in both shapes (26), but the grouped shape never asks or shows the t write's lane views of m1 (m1:15/m1:16).

Why

m1 is plainly pending while m0's flight is up (F-9). The grouped effect reads isPending(m1) beside m1(), so it, and m1 with it, sits in the s write's transaction. The later setT(1) then merges into that open transaction instead of opening its own lane. In the split shape, the value effect isn't held that way, so t gets its own lane and m1 asks its lane questions there.

On next, every shape asked alike only because m1 was re-derived as a verdict reader at every verdict change. That re-derive is the duplicate-ask bug #4397 fixes: each lane question was asked 2–4 times.

Ruling needed

Per the #4284 ruling, JSX grouping must never change the result. Should a later write merge into an open transaction, or open its own lane, when a render effect reads isPending(x) beside x() (the F-6 / D-23 "holds like x() alone" case)?

A test.fails pin in #4397 (verdict-memo-flight-no-reask.test.ts) documents the grouped vs split difference. Probe matrix and repros: review-4397/zz-probe.test.ts, zz-grouping.test.ts and probe-h-wip.txt (project repro folder).

Related, still open

  • In the held two-action and two-verdict probes, m1:15 is still asked twice (base asked it 3–4 times).
  • With #4393 (R5), a second write during the hold (s=3) still asks m0:5 twice.
Lenguaje dominante
TypeScript
Estrellas
36.2k
Forks
1.1k
Merge medio
11 h 48 min
PR fusionados (30 d)
441

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.