Hacktoberfest 2026: những issue maintainer đã đánh dấu cho tháng Mười, đang mở và phù hợp người mới. Xem issue Hacktoberfest

[2.0 / next] Error formatting and async iterator protocol failures escape memo error handling

Đang mở
  • Có gì không ổn?
#4,112 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
22/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ệ
javascript, typescript
Lĩnh vực
frontend

Hướng nghiên cứu

The async escape sites are in packages/signals/src/core/async.ts around the iterator advancement code (it.next(), isThenable(step), settled.then) and the deferred iterable detection near line 704 and its fulfillment callback near line 737. The formatting failure is in StatusError construction in packages/signals/src/core/error.ts near line 49. Start by reproducing with the linked playgrounds, then route the unguarded protocol calls into the memo's error handler. Done when the boundary shows the error for each of the four variants and the controls 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

Some operations Solid performs while processing memo results can throw outside the memo's error handling.

After an async iterator yields, a synchronous throw from a later next() or from the next step's then escapes as an unhandled rejection. The memo keeps its last value and <Errored> never shows its fallback. Iterator setup can escape similarly when a promise resolves to an iterable, leaving <Loading> stuck.

There is also a synchronous escape in error formatting: constructing StatusError can throw out of createMemo(...), replacing the original compute error and aborting initialization.

Your Example Website or App

https://s.olid.uk/id/S8TyGqCDTL-vlxyOuHwbPw

Steps to Reproduce the Bug or Issue

No interaction is needed in these playgrounds:

  1. Later next() throws: open the main repro. After 500 ms it yields 1, then next() throws next failed. The page stays at Value: 1; the console reports an uncaught promise error instead of the boundary displaying Error: next failed.
  2. Next step's then() throws: https://s.olid.uk/id/0ZuFYcLwRBODdfMqTy5O6A — the same sequence leaves Value: 1 and reports then failed outside the boundary.
  3. Deferred iterator setup throws: https://s.olid.uk/id/4U4U3cPFRrSbzA3_uDZLnQ — an async memo resolves to an iterable whose iterator factory throws. The console reports iterator failed, while the page stays on Loading....
  4. Error formatting throws: https://s.olid.uk/id/EtxIswRlT8Ct_xJIWyzIDg — the memo throws a null-prototype object, but formatting it throws a TypeError out of createMemo. The enclosing boundary receives that secondary error, and creation never returns an accessor.

Controls: in the first two examples, return Promise.reject(new Error(...)) from the failing next() branch instead of throwing during the protocol operation. The boundary then displays the error. In the third, throw directly from the async memo after the delay. In the fourth, replace Object.create(null) with {}; the boundary receives the original object.

Expected behavior

Async protocol failures should reach the owning memo's error handler and boundary, as rejected iterator steps already do. A failure should not leave stale content or loading state behind while only producing an unhandled continuation rejection.

Error formatting should also be handled deliberately: best-effort formatting could preserve the original compute error, or a failure considered fatal could deliberately halt. Currently formatting aborts memo creation and the enclosing computation receives a secondary exception.

Screenshots or Videos

No response

Platform
  • OS: Linux
  • Browser: Chromium 154.0.8037.57
  • Solid: hosted playgrounds pinned to next@d5e32a9af41c7bfe0bc090f7438ee4297d540b17.
  • Rechecked against current next@ccd99481deed3ebb567ee11ab7a152ced84d122b, using Chromium with bundles compiled directly from source in both development and production configurations.
Additional context

Verified the following escape variants on current next in both configurations, using native promises for the asynchronous delivery:

Operation When Result
next getter or next() call throws After an async yield Unhandled rejection; last value remains
Next step's then getter or then() call throws After an async yield Unhandled rejection; last value remains
[Symbol.asyncIterator] getter or factory throws After a promise resolves to an iterable Unhandled rejection; memo never delivers an error
First next() throws During that deferred iterator setup Same
Thrown value cannot be stringified, or its toString, Error.message getter, or message conversion throws During initial compute-error handling Secondary exception escapes createMemo

The controls are contained correctly: throwing then getters/methods and iterator factory/next() calls during the initial synchronous computation; later rejected next() promises; and an ordinary async generator throwing after a yield. Across 17 cases per configuration, the seven async escape variants produced the original error as an unhandledrejection but never invoked the memo's error callback. The four formatting variants escaped creation. All six controls delivered the original error. Unrelated reactive updates continued in the escape cases; no deliberate halt occurred. The hosted rejection controls also show their <Errored> fallbacks correctly.

Suspect sites:

  • Iterator advancement and step assimilation: it.next(), isThenable(step), and settled.then(...) are unguarded. The initial call is protected by the compute catch, but later calls run from an async continuation.
  • Deferred iterable detection and its fulfillment callback: reading/calling the iterator protocol and its first pull can throw after the original compute catch has exited. These user-protocol operations need error routing at the asynchronous call sites, alongside the existing rejection handlers.
  • StatusError construction: message extraction and conversion run inside error handling without their own guard. #3886 contains this candidate, which fixes the four checked formatting variants:
- super(original instanceof Error ? original.message : String(original), {
-   cause: original
- });
+ let message: string | undefined;
+ try {
+   message = String(original instanceof Error ? original.message : original);
+ } catch {}
+ super(message, { cause: original });

The formatting change does not address the separate async protocol escape sites. Their failures need to reach the memo's error machinery rather than escape the continuation.

Related: #2918 explicitly handles throwing then getters/methods for actions with await semantics; #2869 fixed synchronously delivered iterator rejections. These memo cases concern throws while invoking the protocol, rather than a rejection delivered through it. #2840 establishes original-error identity. The formatting candidate comes from #3886 and was outside #4085's held-error scope.

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

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.