Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

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

Chiusa
  • Qualcosa non va?
#4,398 1 commento 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
4/5
Tempo stimato
3-5 giorni
Idoneità per principianti
45/100
Tipo di issue
Bug
Chiarezza
Abbastanza chiara
Stato di attività
Attiva
Stack tecnologico
javascript, typescript
Ambito
frontend

Direzione di ricerca

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.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

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.
Lingua principale
TypeScript
Stelle
36.2k
Fork
1.1k
Merge medio
11h 48m
PR unite (30g)
441

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di solidjs/solid

Tutte le issue di solidjs/solid

Issue simili

Altre issue su TypeScript

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.