Hacktoberfest 2026：メンテナが10月に向けて印を付けた、オープンで初心者向けの issue。 Hacktoberfest の issue を見る

rc.9: deferred child recomputation loses REACTIVE_ZOMBIE and leaks subscriptions

クローズ
  • 何か問題がありますか？
#3,543 コメント 1 件 リアクション 0 件 担当者 0 名 GitHub で見る

メンテナーはふだん 1 日以内に返信

まだ誰も着手していません。

評価

難易度
4/5
見積もり時間
3〜5日
初心者へのやさしさ
55/100
issue の種類
バグ
明瞭さ
おおむね明確
活発さ
活発
技術スタック
javascript, typescript
領域
frontend, performance

調査の方向性

リンクされた playground の再現から始め、次に @solidjs/signals/dist/dev-shared.js の recompute、updateIfNecessary、disposeChildren 周辺を調べます。特に、3つのフラグのリセットと REACTIVE_ZOMBIE の処理を確認してください。40-update control と DEV.getObservers を使って、signals を交互に更新すると、アクションの実行待ち中も完了後も2つの subscribers が維持されることを確認します。

索引モデルが issue の本文から書いたものです。

説明

Describe the bug

An unrelated pending action causes subscriptions from a Show condition to accumulate across ordinary signal updates. They remain after the action finishes.

The reduced case uses two ordinary signals, one action, a sibling binding reading the action-written signal, and:

<Show when={n() > 0 && n() < 2}>Visible</Show>

No optimistic store, router, SSR, effects, or application-managed ownership is involved. The compiler creates a nested memo in the condition getter. Repeatedly alternating n between 0 and 1 should keep the graph bounded.

Your Example Website or App

https://s.olid.uk/?id=9ec31682-7443-42c7-b68e-4020eef4d836

Steps to Reproduce the Bug or Issue

Open the linked playground and click Run reproduction once. It runs a 40-update control, starts an action waiting on a promise, and alternates the other signal until Solid emits its real HUGE_FAN_OUT warning (at most 4,200 updates). It then releases and awaits the action.

Each write is followed by public flush(); the loop yields to the browser every 100 updates. Counts use DEV.getObservers, and the warning is captured through OBSERVE.diagnostics.

Observed with published rc.9:

  • No pending action: 2 subscribers after 40 updates.
  • Pending action: 2,000 subscribers after 3,997 updates, triggering HUGE_FAN_OUT.
  • After the action finishes: still 2,000 subscribers.
Expected behavior

Obsolete computations should be disposed. Repeating the same two signal values should keep the subscriber count bounded, including while an unrelated action is pending and after it finishes.

Screenshots or Videos

No response

Platform
  • Solid packages: 2.0.0-rc.9
  • Development DOM build; published native compiler, generate: "dom", dev: true
  • Chromium on Linux/WSL
Additional context

Runtime trace and causal check

In @solidjs/signals/dist/dev-shared.js from rc.9:

  1. The previous child is marked REACTIVE_ZOMBIE and moved to its owner's _pendingFirstChild; its replacement occupies _firstChild.
  2. While an action is parked, an ambient update can rerun the deferred child via zombieQueue.
  3. recompute drops REACTIVE_ZOMBIE in its flag resets (lines 4272 and 4437); updateIfNecessary also drops it in its final mask (line 4802).
  4. disposeChildren(child, true) relies on this flag to skip the ordinary parent-chain splice (around lines 2730–2741). With the flag lost, disposing the old child writes parent._firstChild = null in this single-child case, detaching the replacement.
  5. The replacement remains subscribed, but future owner cleanup cannot reach it.

An instrumented six-update trace showed the deferred child entering recomputation with flags 42 (including zombie 32), reaching disposal with flags 0, and erasing the current child. The orphaned replacement continued recomputing on subsequent updates.

As a causal experiment, preserving REACTIVE_ZOMBIE through those three flag resets in an isolated, in-memory test bundle keeps the count at 2 subscribers after all 4,200 updates and after action completion, with no warning. This is not a proposed fully validated fix; broader transition/ownership regression coverage is still needed.

Originally noticed as increasing CPU stalls while dragging cards with saves in flight. The app had retained compiler memos under Show condition owners matching this mechanism. The reduced case isolates the leak; it does not claim to quantify the full app's per-gesture amplification.

主要言語
TypeScript
スター
36.1k
フォーク
1.1k
平均マージ
13時間 13分
マージ済み PR（30日）
306

環境構築

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

solidjs/solid のほかの issue

solidjs/solid の issue をすべて見る

似ている issue

TypeScript の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。