Svelte 5: `$inspect` make `$effect` run syncronously

[paoloricciuti]

Describe the bug

If you add an $inspect that is listening on a variable that is also listening on an $effect the $effect is run syncronously instead of the next microtask.

<script>
	let count = $state(0);

	function increment() {
		count += 1;
		console.log("in-increment", count);
	}

	$effect(() => {
		console.log("effect", count);
	});
	
	$inspect(count);
</script>

<button onclick={increment}>
	clicks: {count}
</button>

on click it will log

effect 1
update 1
in-increment 1

Reproduction

REPL

Logs

No response

System Info

repl

Severity

annoyance

[paoloricciuti]

@trueadm you might wanna look at this

[dummdidumm]

Ah yeah this is the flush_sync fear I had (this issue is a result of #13199) - thought it's prevented by that additional check we added, but turns out not.

[trueadm]

This isn't a bug though? There are no guarantees on the timing – just that something will happen in the future.

[dummdidumm]

Mhhm you're right that strictly speaking it's not a bug, it's "just" different timing. I'm not sure if people would rely on this timing in some ways. We're saying that effect runs after the dom has updated, which implies other things run first. That there's now a flush_sync hidden in-between due to the presence of a seemingly unrelated $inspect will be very surprising to people. Imagine you update more than one signal in a callback, suddenly the effect runs two times: Example

[trueadm]

Found a solution that voids flushing sync! Woop.

[paoloricciuti]

This isn't a bug though? There are no guarantees on the timing – just that something will happen in the future.

Well I've heard you talk a lot of times about sync effects and their risk and we are seeing the amount of bugs $inspect is causing because it's a "sync effect". So this is a sort of "fix a priori" for something that could lead to problems.

But good that you found a solution 🎉