signals: a chain's verdict flips to false mid-hold where a diamond's stays true (graph shape is observable)

Đã đóng
  • Có gì không ổn?
#4,562 0 bình luận 0 reaction 0 người được giao Xem trên GitHub

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
15/100
Loại issue
Lỗi
Độ rõ ràng
Khá rõ ràng
Mức độ hoạt động
Sôi nổi
Công nghệ
typescript
Lĩnh vực
frontend

Hướng nghiên cứu

Start with settlePendingSource in packages/signals/src/core/async.ts, tracing how a superseded flight's settle retires a pending node's state. Compare the single-arrival chain path with the second-arrival diamond path that re-marks staged errors. Use packages/signals/tests/settle-diamond-revisit.test.ts as the template for a chain pin. Done when the chain yields false:3, true:3, E:boomA, false:6.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

What happens

The same reads produce different frames depending on whether the derivation is a chain or a diamond. During a held action, a chain's isPending drops to false while the hold is still open. A diamond's stays true until the commit. Graph shape shouldn't be observable.

Found while reviewing #4560. It reproduces the same way on next (404d06a) and on #4560, so it isn't caused by that PR.

Repro

const [s, setS] = createSignal(0);
const A = createMemo(async () => {
  const v = s();
  await Promise.resolve();
  if (v === 2) throw new Error("boomA");
  return v;
});
const B = createMemo(() => A() + 1);
// chain:   C = B + 2;  D = C
// diamond: C = A + 2;  D = B + C
const view = createErrorBoundary(() => `${isPending(D)}:` + D(), e => `E:${e().message}`);
createRenderEffect(view, v => log.push(v));

Steps:

  1. Let the first load settle.
  2. setS(1); flush().
  3. Run action(function* () { setS(2); yield new Promise(r => (release = r)); })() and let it tick.
  4. Call release() and let it tick twice.
  5. setS(3); flush(), then let it tick.
Shape Frames
diamond false:3, true:3, E:boomA, false:9
chain false:3, true:3, false:3, E:boomA, false:6

The diamond's frames are pinned in packages/signals/tests/settle-diamond-revisit.test.ts (#4560).

The frames

  1. false:3: the first load committed (A = 0).
  2. true:3: s = 1 is a new question. A's flight is out, D's dependents are pending, and the screen keeps 3.
  3. The action's setS(2) re-asks A inside a hold, superseding the s = 1 flight. That flight throws boomA, and the error is staged in the hold (D-41). The hold stays open until release().
  4. Chain only, false:3: while the hold is still open, the view re-runs and reads isPending(D) === false with the committed 3. The diamond emits nothing here.
  5. E:boomA: the commit publishes the staged error.
  6. false:6 / false:9: s = 3 lands.

Ruling: the chain is wrong (F-9, with F-2)

  • F-9. isPending(x) is true "iff x's value is not the final answer to a new question: an input changed and the new answer has not been committed, a landed answer waits in a hold…". At frame 4 the input has changed (s is 1, then 2 in the hold), no new answer has been committed, and the staged answer is still waiting in the hold. Nothing has answered the s = 1 question; the hold superseded it. So isPending(D) must stay true until the commit, which is what the diamond shows.
  • F-2. "A change that needs async to be shown is held; the screen keeps what it showed." The screen showed true:3. Flipping it to false:3 mid-hold changes what is shown before the commit, with no commit behind the change.

So the expected chain frames are false:3, true:3, E:boomA, false:6.

Where to look

The difference lives in settlePendingSource (packages/signals/src/core/async.ts).

When the superseded flight's source settles, the walk retires D's pending state through the branch that carried it. In the diamond, D is reached a second time through the other branch. That second arrival takes the walk's early-return path, which re-runs a verdict reader or marks a staged error (stageMark), and that keeps D's verdict tied to the staged frame. In the chain there is only one arrival, so nothing re-marks D, and the view re-derives isPending(D) as settled while the hold is still open.

A likely fix is for the chain's single arrival to do what the diamond's second arrival does: a node that inherits the staged error, or whose verdict reads the hold, keeps that mark rather than reading as settled. Pin the chain frames above alongside the diamond pin.

Not fixed in #4560 on purpose: that PR keeps next's behaviour exactly.

Ngôn ngữ chính
TypeScript
Star
36.2k
Fork
1.1k
Merge trung bình
10 giờ 39 phút
Pull request đã merge (30 ngày)
500

Chuẩn bị môi trường

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. 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.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của solidjs/solid

Tất cả issue của solidjs/solid

Issue tương tự

Thêm issue về TypeScript

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.