Svelte 5: derived from factory of derived loses reactivity

[7nik]

Describe the bug

$derived from an expression that always "returns" a new $derived value loses reactivity after a value update.

Reproduction

https://svelte-5-preview.vercel.app/#H4sIAAAAAAAAA2VR22rEIBD9FZF9SNjS0NfcoPQzmj6kOgFpokEnyxbx36sZsw3tg-DMmXMZ9XxSMzhev3uuxwV4zV_XlT9x_F5T4W4wI8Tamc2K1GmdsGrFfsBBDzgDMmE2jaxjF4cjQvFSRiBCwmiHzMIoI1aUrOuZT_0Bqyq2cbOa-UwODSHEuScxCVbdQBaPkTLPZOp9LwN5pRhSWRCnHDS_IyT1F0rnAtMUWUXO9yuSchfl8-7dJHN23iorvh2bH2HPLDL5Z_DIctZoaL22Oh43erWfG6LRzGgxK_HVeZLYta_XkGZQaWFhAY2JS_OZa_u8S808XcLRJt_Up1sE4gcvRqpJgeQ12g3CR_gBwWXfMRsCAAA=

Logs

No response

System Info

Svelte v5.0.0-next.29

Severity

annoyance

[huntabyte]

It seems to only be the case when deriving from a primitive value: REPL

[dummdidumm]

Analysis so far: This line current_skip_consumer = current_effect === null && (signal.f & UNOWNED) !== 0; becomes true for count when referenced within $derived inside the read function, which means count is then not adding x as a consumer, which results in this not rerunning anymore. It's false because current_effect is null because the const derivedCount = $derived(..) where read is executed doesn't set it (only effects set it).

[trueadm]

Fixed in #10213