state_unsafe_mutation caused by {#await}?

[0x1618]

Hi, I have a custom error that triggers a notification. I'm encountering an issue where some functions used alongside the loading process throw this error, causing a state_unsafe_mutation. I'm not entirely sure why this error occurs. Interestingly, if I don't use the LoadingOverlay component and instead move the code outside of it, everything works fine. The same happens if I add a timeout to the awaitable, for example: await new Promise((resolve) => setTimeout(() => resolve(), 2000));

repl: https://svelte.dev/playground/c129be944f8f4c659f73c4c78e15afa5?version=5.11.2

[gterras]

By simply moving the function call to the script it starts working:

const working = wrappedAwaitable()
{#await working}

So it's probably a bug, you should open an issue. With this minimal repro the error message looks adequate.

[0x1618]

It is working. However, I think a more Svelte-like approach is to make #await an exception for this, so you can call the function in the template syntax that changes the state. It is confusing when used with the #await.

[Leonidaz]

was just looking for use cases where signals can be mutated via template effects.

your code could work if this PR lands and if you wrap your signal mutation in a unsafe and also untrack (the latter is to not subscribe while reading the signal during the mutation).

untrack(() => unsafe(() => notificationStackState.push({message})));

PR: #14784

your example with the version from this pr

Still have to be careful and make sure that using unsafe doesn't cause infinite loops (e.g. template effect mutates a signal and that causes the template effect to rerun since the signal is read in the template and that runs the signal mutation again and so on).

Your case should be fine. But I would say that since code tends to change, if you can, it's always better to avoid coupling template effects with signal mutations. And so, the original solution is still more future-proof, in terms of decoupling from the template effect.