Hacktoberfest 2026：维护者为十月标记出来的 issue，仍然开放、适合新手。 浏览 Hacktoberfest issue

2.0.0-rc.14: a derivation reading `latest()` of a held signal gets `{}` as `prev` (`prev is not iterable`)

已关闭
  • 哪里不对？
#3,955 0 条评论 0 个 reaction 已指派 0 人 在 GitHub 查看

维护者通常 1 天内回复

还没有人认领这个 Issue。

评估

难度
3/5
预计耗时
半天
新手友好度
45/100
Issue 类型
缺陷
描述清晰度
描述清楚
活跃度
活跃
技术栈
javascript, typescript
领域
frontend

调研方向

The suspect is recompute in packages/signals/src/core/core.ts on next, where value is picked from el._x._lane when CONFIG_OVERRIDE is set. Run the Node repro in the issue first and confirm it prints prev = {} and throws. Then compare with the compareValue guard a few lines below, which already checks el._x._lane !== NOT_PENDING. Done when the repro prints prev = [] on every run without throwing, and the existing signals tests still pass.

由索引模型根据 Issue 内容生成。

描述

Describe the bug

If a derivation that receives prev — createSignal(fn) or createMemo(fn) — reads latest() (or isPending()) of a signal that an in-flight async memo is holding, it can be re-run with an empty object {} as prev instead of its previous value:

prev = []
prev = []
prev = {}
[REACTIVITY_HALTED] An uncaught error halted the reactive system. … TypeError: prev is not iterable

rc.13 passes the previous value every time, so this is a regression in rc.14. It still reproduces on next at 43570f8, in development and production builds.

We hit it in an app where a list's filter rows are a writable derived signal (createSignal((names = []) => [...names, …])) that reads latest() of the list's filters. A second filter click while the list is still loading throws, and the page stops updating; with a slow API that happens on every run. The repro reduces it to one async memo, one derivation and two writes, and fails every time.

Your Example Website or App

Solid 2.0 playground (rc.14, dev build)

Steps to Reproduce the Bug or Issue

  1. Open the playground link above (pinned to Solid 2.0.0-rc.14, dev build) and wait for data: 0.
  2. Click Write filter twice within a second.
  3. The console logs prev = {} and Uncaught TypeError: prev is not iterable, then REACTIVITY_HALTED; data stays at 0, and further clicks change nothing.

The same playground on rc.13 logs prev = [] on every click and moves data on. In the Node version below, each of these makes it pass, so they are all needed:

  • the async memo reading filter being observed (dropping its render effect, or making it synchronous, means nothing is held)
  • reading filter through latest() (or isPending()) rather than filter()
  • the derivation's first pass during the hold being equals to its previous result (returning a new array that equals rejects passes)
  • the second write landing while the first fetch is still in flight
Same repro in Node

With [email protected] as the only dependency, node --conditions=browser --conditions=development repro.mjs prints prev = {} and flush threw: prev is not iterable; the production build (--conditions=browser only) does the same. On rc.13 both print prev = [] three times.

// node --conditions=browser --conditions=development repro.mjs
// -> prev = [], prev = [], prev = {}, then TypeError: prev is not iterable
import {createRoot, createSignal, createMemo, createRenderEffect, latest, flush} from "solid-js";

const sleep = (ms) => new Promise((r) => setTimeout(r, ms));

const setFilter = createRoot(() => {
  const [filter, setFilter] = createSignal("a");

  // An async memo observed by an effect: a write to `filter` is held until it lands.
  const data = createMemo(async () => { const f = filter(); await sleep(50); return f; });
  createRenderEffect(data, () => {});

  const [names] = createSignal((prev = []) => {
    latest(filter);
    console.log("prev =", JSON.stringify(prev));
    return [...prev];
  }, {equals: (a, b) => a.length === b.length});
  createRenderEffect(names, () => {});

  return setFilter;
});

await sleep(100);
setFilter("b"); // held: `data` is in flight; `names` re-runs in the verdict lane, equal result
flush();
await sleep(10);
setFilter("c"); // still in flight: `names` re-runs with prev = {}
try { flush(); } catch (e) { console.log("flush threw:", e.message); }
await sleep(100);

Expected behavior

prev is the derivation's previous value (here []) on every run.

Screenshots or Videos

N/A — the console output above is the whole symptom.

Platform

  • OS: Linux (Arch, kernel 7.2.2)
  • Browser: Chromium 151 (the playground link, and our app under Vite 8 dev); the Node repro on Node 24.21.0
  • Version: solid-js / @solidjs/signals 2.0.0-rc.14 and next at 43570f8 (dev and production builds)

Additional context

The cause seems to be this line in recompute (dist/dev-shared.js; the same in prod/core/core.js and observe/core/core.js, and in packages/signals/src/core/core.ts on next):

let value =
  el._pendingValue !== NOT_PENDING
    ? el._pendingValue
    : el._config & CONFIG_OVERRIDE
      ? el._x._lane
      : el._value;

The node enters the verdict lane with _x._lane still NOT_PENDING, and an equal first pass never writes it, so the next pass gets NOT_PENDING as prev. The compareValue a few lines further down already guards this case (el._config & CONFIG_OVERRIDE && el._x._lane !== NOT_PENDING). Adding the same check here makes the repro pass, and it fixes our app.

主要语言
TypeScript
星标
36.1k
派生
1.1k
平均合并
12 小时 10 分钟
30 天内合并 PR
338

环境准备

从这里开始

  1. 先读完整个 Issue，再读项目的贡献指南。
  2. 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
  3. Fork 仓库，在一个分支上完成修改。
  4. 提交 Pull Request，并在描述里引用这个 Issue 编号。

solidjs/solid 的其他 Issue

查看 solidjs/solid 的全部 Issue

相似的 Issue

更多 TypeScript Issue

把新 issue 发到你的邮箱

精选适合新手参与的 GitHub issue 摘要。