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

Under a parked transaction, an owner that recreates a child runs twice per mainline write (zombie rerun notifies through the A30-kept tail before the commit trims it)

Chiusa
  • Qualcosa non va?
#3,546 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
68/100
Tipo di issue
Bug
Chiarezza
Specificata chiaramente
Stato di attività
Attiva
Stack tecnologico
typescript
Ambito
frontend, performance

Direzione di ricerca

Inizia dai percorsi delle transazioni parcheggiate ambient in packages/signals/src/scheduler.ts, in particolare runHeap e finalizePureQueue, e verifica il comportamento di owner-height in core.ts. Esegui packages/signals/tests/zombie-recompute-keeps-flag.test.ts, quindi confronta i casi correlati in lane-outside-view.test.ts e transition-orphan-recompute.test.ts. Il lavoro è completato quando il limite del numero di esecuzioni raggiunge controlRuns, mentre entrambi i test correlati di zombie-update continuano a passare.

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

Descrizione

enhancement

Found while fixing #3543. Not a leak, values are identical, but it is a 2× cost on a common shape for as long as any action is pending.

What happens

While any transaction is parked, an owner that recreates a child each pass — a compiled <Show when={n() > 0 && n() < 2}> condition, whose getter is memo(() => n() > 0)() && n() < 2 — runs twice per mainline write, creating and disposing an extra child each time. The zombie child itself runs once.

Per write to n, in the ambient flush (activeTransition === null, transitions.size > 0), from an instrumented run of packages/signals/tests/zombie-recompute-keeps-flag.test.ts:

  1. runHeap(dirtyQueue) (scheduler.ts:796): the owner P recomputes first (a child the owner creates doesn't lift the owner's height, core.ts:1962). It zombifies the old child C1 — still DIRTY|IN_HEAP from the write, so markDisposal migrates it to zombieQueue — creates C2, stages, queuePendingNode(P).
  2. runHeap(zombieQueue) (scheduler.ts:875): C1 reruns as a zombie. Its value changed, so insertSubs notifies its subscribers — and P is still one, because A30 (#3469, 27b24aa06) keeps a staged pass's previous dep tail linked until the commit trims it.
  3. finalizePureQueue(): commitPendingNodes() disposes C1 and trims P's tail — after P is already dirty. The runHeap at scheduler.ts:1323 recomputes P again with identical inputs: zombifies C2, creates C3, commits again.

Measured on that test: 40 alternating writes cost 60 nested-memo runs with no transaction parked and 100 with one parked — the extra 40 are 20 zombie reruns plus 20 second-pass creations. Both are waste: P's staged value from step 1 already reflects the new n, and nothing ever renders C1's rerun.

Why A30 is not the problem

A30 is right to keep the tail: at recompute time nobody knows whether this flush will park, and if it does, the committed frame (which derives from C1) stays on screen and must keep receiving writes (#3469, #3410). The tail dep in #3469 is a live signal written in a later flush — that is the case A30 exists for. Here the tail dep is a zombie that reruns inside the same flush, a few lines before the commit that disposes it. Trimming earlier reopens #3469.

Proposal

Zombies whose owner commits this flush should not rerun before that commit. Concretely, in the ambient-with-parked-transactions branch, commit pending nodes before running the zombie queue (or run the zombie queue after finalizePureQueue and before the effect phases). A zombie whose owner commits is disposed by the commit and never reruns — which is already what happens when no transaction is parked (zombieQueue isn't run at all). Only zombies of actually-parked owners rerun, which is what :875 is for (#2916, #3463), and their owners' tails are legitimately kept.

Alternative if the ordering is load-bearing elsewhere: in insertSubs, skip a subscriber whose link to the notifying node lies past its _depsTail (a held-trim tail) when the notifier is a zombie — the notification is to a frame this flush is replacing, not to the live pass. Narrower, but it leaves the pointless zombie rerun in place.

Acceptance: the run-count bound in zombie-recompute-keeps-flag.test.ts (controlRuns + 40, currently exact) tightens to controlRuns; lane-outside-view.test.ts (#3463) and transition-orphan-recompute.test.ts ("still updates zombies for mainline writes in a separate flush") stay green.

Related: #3543 (the flag loss this surfaced), #3469 / A30, #3463, #3410.

Lingua principale
TypeScript
Stelle
36.1k
Fork
1.1k
Merge medio
13h 13m
PR unite (30g)
306

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.