Why were async effects/store setters **removed** in 2.0?

[FlameWolf]

In Solid 1.x, one could call async callbacks in createEffect/setStore methods like this.

/* Effect */
createEffect(
	on(
		() => state.autoSyncEnabled,
		/* async handler */
		async flag => {
			await setKV(AUTO_SYNC_KEY, flag);
		},
		{ defer: true }
	)
);
/* Store */
setStore(
	"notes",
	/* async handler */
	produce(async notes => {
		const targetNotes = notes.filter(note => idSet.has(note.id));
		targetNotes.forEach(mutator);
		await notesRepository.saveManyMeta(unwrap(targetNotes));
	})
);

Looks like that's no longer possible in solid 2.0.

/* Effect */
createEffect(
	() => state.autoSyncEnabled,
	async flag => { /* Error! */
		await setKV(AUTO_SYNC_KEY, flag);
	},
	{ defer: true }
);
/* Store */
setStore(async value => { /* Error! */
	const targetNotes = value.notes.filter(note => idSet.has(note.id));
	targetNotes.forEach(mutator);
	await notesRepository.saveManyMeta(snapshot(targetNotes));
});

Seems strange since a big part of the new release is async being first class. But currently it removes async features that were previously supported.

Why?

[FlameWolf]

CC: @ryansolid

[mizulu]

I have suggested supporting async better in the primitive
but this is something that can be implemented as a community primitive.

hopefully this can also be added to the solid es lint rule
because this is likely to be a common use/mistake.

https://mizulu.users.s.olid.uk/create-effect-async-callback-and-cleanup-support/

this issue exists in createEffect and also in onSettled
both has cleanup function as returned function in the callback.
calling an async function always returns a promise so it fails when it tries to use it as a cleanup function.

[ryansolid]

Nothing was removed. 1.x never supported async in either of these places; it didn't check for it, and the two examples worked for two different accidental reasons.

createEffect in 1.x ignored the callback's return value (it became prev for the next run), so an async function's promise was quietly discarded. The effect had no idea the work was still in flight, couldn't cancel it when the dependency changed again, and two runs could race each other's writes. produce(async …) worked because the writable proxy stayed writable after the await, so the writes after the await landed as individual unbatched store writes, outside the setter, whenever the promise happened to resume. Neither of those is a feature. Both are the absence of a check.

2.0 makes the check explicit, for two reasons that come from the model rather than from wanting to be strict:

The effect callback's return is its cleanup. An async function always returns a Promise, so the runtime can't get a cleanup out of it and can't order the work against the next run. Cleanup-before-next-run is the whole point of cleanup; silently accepting a Promise would be promising something the runtime can't deliver. So it's an error, in dev, at the moment you write it.

A store setter is a synchronous transaction. Open the draft, apply the writes, commit and notify once at exit. That's what lets stores participate in transitions, optimistic updates and actions: the engine needs to know the batch is complete. After the first await the draft is closed and anything you write to it is outside the transaction. (Checked on current next: that post-await write is currently dropped silently at runtime and only the types stop you — that should become a dev error like the effect case.)

Async is first class in 2.0, in the two places where it has a defined meaning: derivation and orchestration. Reads derive from promises and async generators (createMemo/createAsync, resolve, until), and async mutation flows live in action(), which is the transaction primitive that knows how to leave and re-enter across an await:

const setAutoSync = action(async function* (flag: boolean) {
  setStore(s => { s.autoSyncEnabled = flag; });   // sync write, inside the transaction
  await setKV(AUTO_SYNC_KEY, flag);               // side effect
  yield;                                          // re-enter if you have more writes to make
});

const saveNotesMeta = action(async function* (idSet: Set<string>, mutator: (n: Note) => void) {
  setStore(s => { for (const n of s.notes) if (idSet.has(n.id)) mutator(n); });
  const changed = snapshot(store.notes).filter(n => idSet.has(n.id));
  await notesRepository.saveManyMeta(changed);
});

That's the second example, and it's better than the 1.x version: the store write is one committed batch, the persistence call sees the committed snapshot rather than a half-mutated proxy, and the action tracks the pending state for you.

The first example is a side effect in response to a change, which is exactly what createEffect is for; it just has to be honest about the async part:

createEffect(
  () => state.autoSyncEnabled,
  flag => {
    const ac = new AbortController();
    setKV(AUTO_SYNC_KEY, flag, { signal: ac.signal }).catch(reportError);
    return () => ac.abort();
  },
  { defer: true }
);

Or, if fire-and-forget is genuinely what you want, flag => { void setKV(AUTO_SYNC_KEY, flag); }. That is what 1.x was doing anyway; now it's written down.

On the wrapper linked above: it's fine as a userland convenience if you understand what it changes. The cleanup returned from the async body is deferred until the promise settles, which means it can run after the next run's effect has already begun, and nothing cancels the in-flight work. It also swallows non-function returns, which hides exactly the mistake the core error exists to catch. That's why it isn't in core: it redefines what "cleanup" means, and core can't quietly do the wrong thing. A lint rule for async in effect callbacks is a reasonable addition to eslint-plugin-solid; the runtime already catches it in dev, so the lint just moves the message earlier.

— Claude via Cursor