Derived value not receiving updates

[tBuLi12]

Describe the bug

When a value twice derived is used in a computed expression which is the value of a prop/argument of a component/snippet with a default value it may not always receive updates when the underlying state changes. Please see the reproduction section for more details.

Occurs in versions 5.19.5 and above.

Reproduction

See minimal reproducible example in the repls below:

Displays 0, incorrect
REPL@5.19.5

Displays 1, correct
REPL@5.19.4

System Info

System:
    OS: Windows 11 10.0.26100
    CPU: (32) x64 AMD Ryzen 9 9950X 16-Core Processor
    Memory: 34.45 GB / 61.58 GB
  Binaries:
    bun: 1.2.13 - ~\AppData\Local\Temp\bun-node-64ed68c9e\bun.EXE
  Browsers:
    Edge: Chromium (136.0.3240.50)
  npmPackages:
    svelte: ^5.33.14 => 5.33.14

Severity

blocking an upgrade

[raythurnvoid]

This PR introduced this regression: #15137

[raythurnvoid]

This seems much more nasty than what i thought and the issue seems to be reproducible only in dev mode. (pnpm run dev)

In production mode the app behaves as expected. (pnpm run build && pnpm run preview)

[tBuLi12]

the issue seems to be reproducible only in dev mode

That's odd, I remember experiencing it in prod mode as well. I was using the esbuild svelte plugin tho, maybe it passes dev: true to the svelte compiler by default. Or maybe causing this in production requires more steps, which I've lost when minimizing the example in dev mode.

[raythurnvoid]

Try again perhaps, svelte codebase changed since then so maybe the issue got fixed indirectly but only in prod mode that sounds weird to me as well.

What i did was: create svelte proj with pnpm create vite then pnpm install > pnpm run build > pnpm run preview and the UI shows "1" (correct)

Only pnpm run dev shows "0" (incorrect).

The way i found out about this is because i was unable to write a test in svelte that would fail for this case and then i forced dev: true and magically the test was now failing!

[tBuLi12]

After some fiddling I noticed that the issue only occurs in prod when the value is passed to a component, not a snippet. That's how I originally encountered the issue, but I exchanged it for a snippet for simplicity when testing in dev mode.

You can use a dummy component like this instead of the snippet to reproduce it:

<script lang="ts">
    let { value = 0 } = $props();
</script>

[raythurnvoid]

Interesting! @paoloricciuti did a fix for this, I will check if it works with the component version as well.

I also want to understand why dev mode behaves different, it definitely shouldn't

[paoloricciuti]

The fix works also in the actual case ...I wonder if the dev only behavior is caused by wrap_snippet then

[raythurnvoid]

The fix works also in the actual case ...I wonder if the dev only behavior is caused by wrap_snippet then

Yes the difference is wrap_snippet, in prod mode is not generated (i guess because it doesn't do anything).

In dev mode however that is what causes the chain of things that ultimately leads to mark the derived as MAYBE_DIRTY and from not being recomputed again when needed in the original code

wrap_snippet calls $.fallback that requries $.get from derived > $.get calls check_dirtiness that calls update_reaction that sets skip_reaction to true because active_reaction is null > update_reaction of derived2 recursively calls check_dirtiness of derived1 that also calls update_reaction > everything good so far but in the finally block of update_reaction of derived1 skip_reaction that now is false for derived1 is set to previous_skip_reaction that was true > when update_reaction exits updated_derived is called, skip_reaction is true and the derived1 is marked as MAYBE_DIRTY.

After the whole thing finishes derived1 is MAYBE_DIRTY and derived2 is CLEAN, the next time we write override internal_set should recursively go through all its reactions and mark_reactions as MAYBE_DIRTY but it will skip derived1 that is already MAYBE_DIRTY and by skipping it it also ultimately not queue the flush of the effects that depends on derived2 that depends on derived1