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

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.

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:

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.