2.0.0-rc.14: a derivation reading `latest()` of a held signal gets `{}` as `prev` (`prev is not iterable`)
Maintainer thường phản hồi trong vòng 1 ngày
Chưa có ai nhận issue này.
Đánh giá
- Độ khó
- 3/5
- Thời gian dự kiến
- Nửa ngày
- Mức phù hợp với người mới
- 45/100
- Loại issue
- Lỗi
- Độ rõ ràng
- Đặc tả rõ ràng
- Mức độ hoạt động
- Sôi nổi
- Công nghệ
- javascript, typescript
- Lĩnh vực
- frontend
Hướng nghiên cứu
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.
Do mô hình lập chỉ mục viết ra từ nội dung của issue.
Mô tả
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
- Open the playground link above (pinned to Solid 2.0.0-rc.14, dev build) and wait for
data: 0. - Click Write filter twice within a second.
- The console logs
prev = {}andUncaught TypeError: prev is not iterable, thenREACTIVITY_HALTED;datastays at0, 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
filterbeing observed (dropping its render effect, or making it synchronous, means nothing is held) - reading
filterthroughlatest()(orisPending()) rather thanfilter() - the derivation's first pass during the hold being
equalsto its previous result (returning a new array thatequalsrejects 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/signals2.0.0-rc.14 andnextat 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.
- Ngôn ngữ chính
- TypeScript
- Star
- 36.1k
- Fork
- 1.1k
- Merge trung bình
- 10 giờ 44 phút
- Pull request đã merge (30 ngày)
- 339
Chuẩn bị môi trường
- Không có Dockerfile hay tệp Docker Compose
- Có mẫu pull request
- Đọc hướng dẫn đóng góp
Bắt đầu từ đâu
- Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
- Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
- Fork repository và làm thay đổi trên một nhánh.
- Mở pull request có tham chiếu số hiệu của issue.
Issue khác của solidjs/solid
-
Độ khó 4/5 3-5 ngày Mức phù hợp với người mới 50/100
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 4/5 3-5 ngày Mức phù hợp với người mới 28/100
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 4/5 3-5 ngày Mức phù hợp với người mới 45/100
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 3/5 1-2 ngày Mức phù hợp với người mới 58/100
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 5/5 Hơn một tuần Mức phù hợp với người mới 35/100
Maintainer thường phản hồi trong vòng 1 ngày
Tất cả issue của solidjs/solid
Issue tương tự
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 77/100
apache/rocketmq-dashboard#6610 ·
Maintainer thường phản hồi trong vòng 3 ngày
-
nextjs-tracking
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 69/100
cloudflare/vinext#3920 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Team:Dashboards
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 65/100
elastic/kibana#297299 · 1 bình luận ·
Maintainer thường phản hồi trong vòng 1 ngày
-
analytics beginner friendly community contributions-welcome good first issue hacktoberfest help wanted up-for-grabs
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 82/100
Maintainer thường phản hồi trong vòng 1 ngày
-
affected/v17 affected/v18 area/frontend type/bug
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 82/100
umbraco/Umbraco-CMS#24186 ·
Maintainer thường phản hồi trong vòng 2 ngày