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

rc.14: an effect that catches NotReadyError from an async store is never re-run when the store settles

オープン
  • 何か問題がありますか？
#4,070 コメント 0 件 リアクション 0 件 担当者 0 名 GitHub で見る

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

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

評価

難易度
4/5
見積もり時間
3〜5日
初心者へのやさしさ
25/100
issue の種類
バグ
明瞭さ
明確に書かれている
活発さ
活発
技術スタック
javascript, typescript
領域
frontend

調査の方向性

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.

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

説明

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.

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

環境構築

はじめの一歩

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

solidjs/solid のほかの issue

solidjs/solid の issue をすべて見る

似ている issue

TypeScript の issue をもっと見る

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

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