rc.14: an effect that catches NotReadyError from an async store is never re-run when the store settles
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ó
- 4/5
- Thời gian dự kiến
- 3-5 ngày
- Mức phù hợp với người mới
- 25/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
Start with the headless repro.mjs in the issue, which pins @solidjs/signals to 2.0.0-rc.13 and then rc.15 to compare effect re-runs. The payload names no source files, so locate where NotReadyError is thrown for async store derives and where an effect is scheduled to re-run when that derive settles. Done means the effect with try/catch records ["not-ready","len=1"] again on the current version, matching rc.13, and the without-try/catch case still passes.
Do mô hình lập chỉ mục viết ra từ nội dung của issue.
Mô tả
Summary
@solidjs/[email protected] and rc.15 (dev and prod builds). Regression since rc.13.
An effect whose compute reads an async-seeded store (createStore(async fn, [])) and catches the NotReadyError that read throws runs once with its fallback value and is never re-run when the store's seed settles. The store itself settles: an untracked read afterwards returns the data. The same effect without the try/catch holds and then runs once with the settled value, as before. An async createMemo read the same way is still re-run on rc.15, so this looks specific to async store derives.
const [rows] = createStore(async () => await request, []);
createEffect(
() => { try { return `len=${rows.length}`; } catch { return "not-ready"; } },
(v) => seen.push(v),
);
// rc.13: ["not-ready", "len=1"] rc.14 / rc.15: ["not-ready"], forever
Reproduction (headless, only @solidjs/signals)
mkdir solid-catch-notready && cd solid-catch-notready
npm init -y >/dev/null && npm pkg set type=module && npm i @solidjs/[email protected] >/dev/null
cat > repro.mjs <<'JS'
// An effect whose compute catches NotReadyError from an async-seeded store
// is re-run when the seed settles (rc.13) — or never again (rc.14, rc.15).
import { createEffect, createRoot, createStore, flush } from "@solidjs/signals";
const tick = (ms) => new Promise((r) => setTimeout(r, ms));
for (const caught of [false, true]) {
let resolve;
const request = new Promise((r) => (resolve = r));
const seen = [];
const dispose = createRoot((dispose) => {
const [rows] = createStore(async () => await request, []);
createEffect(
() => {
if (!caught) return `len=${rows.length}`;
try { return `len=${rows.length}`; } catch { return "not-ready"; }
},
(v) => { seen.push(v); },
);
return dispose;
});
flush();
resolve([{ id: "a" }]);
await tick(10);
flush();
console.log(`${caught ? "with try/catch " : "without try/catch"}: ${JSON.stringify(seen)}`);
dispose();
}
JS
node repro.mjs
@solidjs/signals |
without try/catch | with try/catch |
|---|---|---|
| 2.0.0-rc.13 | ["len=1"] |
["not-ready","len=1"] |
| 2.0.0-rc.14 | ["len=1"] |
["not-ready"] |
| 2.0.0-rc.15 | ["len=1"] |
["not-ready"] |
Replacing the store with const memo = createMemo(async () => await request) (reading memo().length) gives ["not-ready","len=1"] on rc.15.
(Pin @solidjs/signals directly: npm i [email protected] alone installs the newest signals through its caret dependency.)
Where we hit it
@dschz/solid-flow pins its async store factories (createNodeStore(async () => …), a thin wrapper over createStore(fn, [])) with this exact effect, which records "not-ready" until the first value and then the row count. Two of its tests fail on rc.14 and rc.15. The library itself never catches NotReadyError, so for us this is a test idiom, but a user's effect that degrades gracefully while data loads would stay on its fallback forever.
If catching NotReadyError in a compute is not a supported pattern, a dev diagnostic for it would help: today the effect silently never updates.
- Ngôn ngữ chính
- TypeScript
- Star
- 36.1k
- Fork
- 1.1k
- Merge trung bình
- 12 giờ 10 phút
- Pull request đã merge (30 ngày)
- 338
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
-
`lazy()`: remounting an already-loaded component renders empty (or the Suspense fallback) since 1.9.14Có thể đã có người làm @itisrmk đã nhận 1 ngày trước. Đang mở
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 62/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 18/100
Maintainer thường phản hồi trong vòng 1 ngày
-
[2.0 / next] Error formatting and async iterator protocol failures escape memo error handlingĐang mở
Độ khó 4/5 3-5 ngày Mức phù hợp với người mới 22/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 14/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 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 76/100
paperclipai/paperclip#16785 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 82/100
code-yeongyu/senpi#3661 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
community first-timers-only good first issue hacktoberfest help wanted low hanging fruit up-for-grabs
Độ khó 1/5 Dưới một giờ Mức phù hợp với người mới 78/100
lingdojo/kana-dojo#32731 · 1 bình luận · 5 reaction ·
Maintainer thường phản hồi trong vòng 1 ngày
-
bug status: needs triage
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 76/100
mastra-ai/mastra#27538 · 1 bình luận ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 72/100
Yeachan-Heo/oh-my-codex#3822 ·
Maintainer thường phản hồi trong vòng 1 ngày