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

2.0.0-rc.18 | `await refresh(memo)` hangs in an action after an optimistic write and a dependency change

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

维护者通常 1 天内回复

@brenelz 已经在做这个了。

开始于 2026年10月25日。

  • #4267 来自 @brenelz —— 未关闭

评估

难度
4/5
预计耗时
3-5 天
新手友好度
57/100
Issue 类型
缺陷
描述清晰度
描述清楚
活跃度
活跃
技术栈
javascript, node.js, typescript
领域
backend, testing

调研方向

Start with the reproduction in the issue body and the @solidjs/signals implementation of action, createOptimistic, and refresh; the issue reports that the behavior also reproduces on the next branch. Run the supplied Node.js reproduction and compare it with the listed variations to narrow down the interaction. Done means refresh(m) resolves, the action completes, and likes() returns 2 in the hanging case.

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

描述

Describe the bug

In an action, await refresh(memo) does not resolve when all of the following happen:

  1. The action writes an optimistic value derived from an async memo.
  2. A dependency of the memo changes during the action, and the memo re-runs and returns a new value (a different object).
  3. After that re-run has settled, refresh(memo) is awaited inside an async function that the action yields.

The action's promise does not resolve either (still pending after 10 seconds in my tests), and likes() keeps returning the optimistic value 3, although the memo takes 5 ms.

Your Example Website or App

https://stackblitz.com/edit/vzxgvake?file=index.js

It runs npm start on open and prints timeout likes = 3.

Steps to Reproduce the Bug or Issue

Run this as an ES module with Node.js:

import {
  action,
  createMemo,
  createOptimistic,
  createSignal,
  flush,
  refresh,
} from '@solidjs/signals';

const tick = (ms) => new Promise((resolve) => setTimeout(resolve, ms));

const [s, setS] = createSignal(0);
// Returns a new object on every run, so each re-run produces a new value.
const m = createMemo(async () => {
  s();
  await tick(5);
  return { likes: 2 };
});
const [likes, setLikes] = createOptimistic(() => m().likes);
flush();
await tick(50);

const run = action(function* () {
  setLikes(likes() + 1); // (1) optimistic write
  yield (async () => {
    await tick(5);
    setS(1); // (2) dependency of `m` changes, so `m` re-runs
    await tick(30); // (3) wait until the re-run settles
    await refresh(m); // does not resolve
  })();
});

const result = await Promise.race([
  run().then(() => 'resolved'),
  tick(2000).then(() => 'timeout'),
]);
console.log(result, 'likes =', likes());

Output:

timeout likes = 3

The table shows the result of each change to the reproduction. The results are the same on rc.15, rc.18, and the current next branch.

Change Result
Remove the optimistic write (1) resolved, likes = 2
Derive the optimistic value from a constant instead of m (createOptimistic(() => 2)) resolved, likes = 2
Remove setS(1) (2) resolved, likes = 2
Wait 1 ms instead of 30 ms at (3), so refresh starts while the re-run is still pending resolved, likes = 2
The memo returns 2 instead of { likes: 2 } (and createOptimistic(() => m())), so the re-run returns an equal value resolved, likes = 2
Yield refresh(m) directly from the generator (code below) resolved, likes = 2
Call setS(1) in a generator step and keep await refresh(m) inside the yielded async function (code below) timeout, likes = 3

Yielding refresh(m) directly from the generator, which resolves:

const run = action(function* () {
  setLikes(likes() + 1);
  yield (async () => {
    await tick(5);
    setS(1);
    await tick(30);
  })();
  yield refresh(m);
});

Calling setS(1) in a generator step, which still hangs:

const run = action(function* () {
  setLikes(likes() + 1);
  yield tick(5);
  setS(1);
  yield (async () => {
    await tick(30);
    await refresh(m);
  })();
});

Expected behavior

await refresh(m) resolves after the memo re-runs, run() resolves, and likes() returns 2.

The documentation of refresh in dist/types/signals.d.ts says that it returns "a promise for the target's NEXT QUIESCENT STATE" and that "Accessor targets resolve with the settled value". In the hanging case, the memo has run three times (initial run, re-run from setS, re-run from refresh) and m() returns { likes: 2 }, but the promise does not resolve.

Screenshots or Videos

None.

Platform

  • OS: Windows 11
  • Runtime: Node.js 24.16.0 (no browser involved)
  • Version: @solidjs/signals 2.0.0-rc.15 and 2.0.0-rc.18

It also reproduces on the next branch at 4ea2f49 (2026-10-25), with dist/dev.js and dist/prod built by rollup -c in packages/signals. Every row of the table above gives the same result there.

Additional context

Workaround: yield refresh(m) from the generator instead of awaiting it inside a yielded async function.

I found this in a framework that passes component props through signals. A parent re-render during a user action can set a prop to a new object. Then a memo that reads the prop returns a new value, and the action, which wrote an optimistic value and then awaits refresh, hangs.

主要语言
TypeScript
星标
36.2k
派生
1.1k
平均合并
11 小时 19 分钟
30 天内合并 PR
337

环境准备

从这里开始

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

solidjs/solid 的其他 Issue

查看 solidjs/solid 的全部 Issue

相似的 Issue

更多 TypeScript Issue

把新 issue 发到你的邮箱

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