Repository navigation
[2.0] The MIGRATION.md replacement for from() keeps the upstream subscription after dispose; add a subscription helper #4182
Description
Describe the bug
documentation/solid-2.0/MIGRATION.md ("from / observable → async iterators / effects") recommends:
const value = createMemo(async function* () {
for await (const val of observable$) yield val;
});After the owner is disposed, the upstream iterator's return() is not called. It runs only when the upstream produces another value, which may never happen. The cause is that the generator is suspended at an await (inside for await), so its return() is queued behind the pending step. Solid's side is correct: consumeIterator calls return() on dispose and on supersede.
Your Example Website or App
Minimal repro inline below (signals-only).
Steps to Reproduce the Bug or Issue
import { createMemo, createRoot, createRenderEffect, flush } from "@solidjs/signals";
let push: (v: number) => void;
let closed = 0;
const observable$: AsyncIterable<number> = {
[Symbol.asyncIterator]: () => ({
next: () => new Promise(r => (push = v => r({ value: v, done: false }))),
return: async () => { closed++; return { value: undefined, done: true }; }
})
};
const dispose = createRoot(d => {
const value = createMemo(async function* () { for await (const v of observable$) yield v; }, { loadingValue: 0 });
createRenderEffect(value, v => console.log("value", v));
return d;
});
flush(); push!(1); /* await a few microtasks */ flush(); // logs 0, 1
dispose(); /* await 50 microtasks */
console.log(closed); // 0: upstream still subscribed
push!(2); /* await */
console.log(closed); // 1: closes only after the next upstream valueBy contrast, a hand-written iterator whose return() unsubscribes synchronously behaves well. I tested:
isPendingstaysfalsewhile the memo waits for the next value;loadingValuecovers the first read;return()unsubscribes immediately on dispose;- bursts coalesce into one update with a dirty flag.
It's about 20 lines and easy to get wrong:
function fromSubscription<T>(subscribe: (cb: () => void) => () => void, getSnapshot: () => T): AsyncIterable<T> {
return {
[Symbol.asyncIterator]() {
let dirty = true, done = false;
let wake: ((r: IteratorResult<T>) => void) | undefined;
const unsubscribe = subscribe(() => {
dirty = true;
if (wake) { const w = wake; wake = undefined; dirty = false; w({ value: getSnapshot(), done: false }); }
});
return {
next: () => {
if (done) return Promise.resolve({ value: undefined, done: true });
if (dirty) { dirty = false; return Promise.resolve({ value: getSnapshot(), done: false }); }
return new Promise(r => (wake = r));
},
return: () => {
done = true; unsubscribe();
wake?.({ value: undefined, done: true }); wake = undefined;
return Promise.resolve({ value: undefined, done: true });
}
};
}
};
}Expected behavior
- Docs: fix the MIGRATION.md snippet so disposal actually unsubscribes, and document (or flag in dev) that
async function*+awaitdelays teardown until the next upstream value. - API: provide a helper equivalent to React's
useSyncExternalStore/ Solid 1'sfrom:MIGRATION.md says this is expected to "move into @solid-primitives". Given how central external stores are to incremental migrations (keeping existing domain stores and putting Solid on top), it may be worth a minimal version in core. Either way, a correct, reusable implementation should exist somewhere official.const online = createMemo(() => fromSubscription(subscribe, () => navigator.onLine), { loadingValue: true });
Screenshots or Videos
No response
Platform
- OS: macOS (Darwin 25.5)
- Browser: n/a (reproduced in Node v24.18.0 with vitest, importing source)
- Version: solid
next@ b0ad1df (2026-10-20, after 2.0.0-rc.16)
Additional context
This came up while documenting useSyncExternalStore for the From React page (solidjs/solid-docs#1664). The From React additions describe the hand-written iterator and warn against async function* for this.
Activity
devagrawal09 commentedon Oct 21, 2026
Prompt cleanup for
async function*computes needs a hook from SolidFollow-up to the
MIGRATION.mdnote in #4183. For now, that PR accepts that cleanup is delayed for generator-basedfrom()replacements. Here's why there isn't a good user-side fix, and some options for a proper one.The problem: JavaScript can't interrupt an
await. A generator paused atawait source.next()only resumes when that promise settles. Solid already tears down a replaced or disposed stream immediately (_flightTeardown→ the iterator'sreturn()), but for a generator thatreturn()is queued behind the pendingawait. Whatever closes the source has to run outside the generator, at teardown time, and user code has no hook for that moment.What I tried on
next@ b0ad1df: a memo whose source is chosen by a signal, plus a filter and a scale. Source A is replaced by B, then the owner is disposed.async function*+for await(the currentMIGRATION.mdexample)onCleanup(() => it.return())in the computeonCleanupinside the generator body, before the firstawaitreturn()closes the source firstonCleanupfalls short because cleanups registered during a run are held until the replacement value commits. That's fine for values, but a replaced run's values are thrown away anyway, so keeping its source alive gains nothing.Options:
createMemo(async function* (prev, { signal }) { … })or agetAbortSignal()usable before the firstawait. It's standard, works withfetchand anything else that acceptsAbortSignal, and also covers cancelling replaced requests (not just streams).iterate(source)helper built on option 1, sofor await (const v of iterate(source))finishes and closes the source on teardown. User code stays a plain generator. It pairs naturally with thefromSubscriptionhelper this issue already asks for.onCleanupcallbacks registered during an async run when that run is torn down, rather than when its replacement commits. This adds no API, and code people already write would start working. But it changes a timing contract, so it needs a decision on whether anything relies on held cleanups for replaced runs.My preference is 1 with 2 on top. 3 is the smallest change if held cleanups for replaced runs aren't relied on anywhere.
ryansolid commentedon Oct 22, 2026
Generated by Claude Code