signals: a chain's verdict flips to false mid-hold where a diamond's stays true (graph shape is observable)

Chiusa
  • Qualcosa non va?
#4,562 0 commenti 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
15/100
Tipo di issue
Bug
Chiarezza
Abbastanza chiara
Stato di attività
Attiva
Stack tecnologico
typescript
Ambito
frontend

Direzione di ricerca

Start with settlePendingSource in packages/signals/src/core/async.ts, tracing how a superseded flight's settle retires a pending node's state. Compare the single-arrival chain path with the second-arrival diamond path that re-marks staged errors. Use packages/signals/tests/settle-diamond-revisit.test.ts as the template for a chain pin. Done when the chain yields false:3, true:3, E:boomA, false:6.

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

Descrizione

What happens

The same reads produce different frames depending on whether the derivation is a chain or a diamond. During a held action, a chain's isPending drops to false while the hold is still open. A diamond's stays true until the commit. Graph shape shouldn't be observable.

Found while reviewing #4560. It reproduces the same way on next (404d06a) and on #4560, so it isn't caused by that PR.

Repro

const [s, setS] = createSignal(0);
const A = createMemo(async () => {
  const v = s();
  await Promise.resolve();
  if (v === 2) throw new Error("boomA");
  return v;
});
const B = createMemo(() => A() + 1);
// chain:   C = B + 2;  D = C
// diamond: C = A + 2;  D = B + C
const view = createErrorBoundary(() => `${isPending(D)}:` + D(), e => `E:${e().message}`);
createRenderEffect(view, v => log.push(v));

Steps:

  1. Let the first load settle.
  2. setS(1); flush().
  3. Run action(function* () { setS(2); yield new Promise(r => (release = r)); })() and let it tick.
  4. Call release() and let it tick twice.
  5. setS(3); flush(), then let it tick.
Shape Frames
diamond false:3, true:3, E:boomA, false:9
chain false:3, true:3, false:3, E:boomA, false:6

The diamond's frames are pinned in packages/signals/tests/settle-diamond-revisit.test.ts (#4560).

The frames

  1. false:3: the first load committed (A = 0).
  2. true:3: s = 1 is a new question. A's flight is out, D's dependents are pending, and the screen keeps 3.
  3. The action's setS(2) re-asks A inside a hold, superseding the s = 1 flight. That flight throws boomA, and the error is staged in the hold (D-41). The hold stays open until release().
  4. Chain only, false:3: while the hold is still open, the view re-runs and reads isPending(D) === false with the committed 3. The diamond emits nothing here.
  5. E:boomA: the commit publishes the staged error.
  6. false:6 / false:9: s = 3 lands.

Ruling: the chain is wrong (F-9, with F-2)

  • F-9. isPending(x) is true "iff x's value is not the final answer to a new question: an input changed and the new answer has not been committed, a landed answer waits in a hold…". At frame 4 the input has changed (s is 1, then 2 in the hold), no new answer has been committed, and the staged answer is still waiting in the hold. Nothing has answered the s = 1 question; the hold superseded it. So isPending(D) must stay true until the commit, which is what the diamond shows.
  • F-2. "A change that needs async to be shown is held; the screen keeps what it showed." The screen showed true:3. Flipping it to false:3 mid-hold changes what is shown before the commit, with no commit behind the change.

So the expected chain frames are false:3, true:3, E:boomA, false:6.

Where to look

The difference lives in settlePendingSource (packages/signals/src/core/async.ts).

When the superseded flight's source settles, the walk retires D's pending state through the branch that carried it. In the diamond, D is reached a second time through the other branch. That second arrival takes the walk's early-return path, which re-runs a verdict reader or marks a staged error (stageMark), and that keeps D's verdict tied to the staged frame. In the chain there is only one arrival, so nothing re-marks D, and the view re-derives isPending(D) as settled while the hold is still open.

A likely fix is for the chain's single arrival to do what the diamond's second arrival does: a node that inherits the staged error, or whose verdict reads the hold, keeps that mark rather than reading as settled. Pin the chain frames above alongside the diamond pin.

Not fixed in #4560 on purpose: that PR keeps next's behaviour exactly.

Lingua principale
TypeScript
Stelle
36.2k
Fork
1.1k
Merge medio
10h 39m
PR unite (30g)
500

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.