Reactivity broken after ~5.43.0

[rallets]

Describe the bug

Ref: https://github.com/sveltejs/svelte/issues/17239#issuecomment-3576002582

If you don't use any async features, probably it's better not to update Svelte until it's ready? Also, I agree that a separate experimental branch for both Svelte and Kit is probably better for all. There are a lot of core api reworks meant to fix async, but they also affect those who don't use the experimental features.

@henrykrinkle01 @dummdidumm
Hi, would you mind explain a bit better what this until it's ready means? We do not use the new async feature in components, all the async work is made in external stores. We got some production bugs due to something related to this issue: we just updated the svelte version, nothing else, app out in production for a while, so we are pretty sure the cause is Svelte itself.
After fixing this issue, it still persist the same problem, but we can say it's "better".
It's not easy to submit a minimal repro.
We need to keep svelte to 5.43.0 that is a working version. I saw in the latest versions some refactoring around the reactivity internals, that could be connected to this issue. Do you have any plans about when it could be done? Or we just need to wait for svelte 6 ?
Now our team has missed trust on Svelte release cycle, unfortunately, it's hard to disagree with them.

Here a repro the replicate our code pattern and the interesting part is:

// from svelte 5.43.0 the local store need to be resetted to be able to get an updated derived.
// this.selectedGroupId = undefined;
// this.selectedPointId = undefined;

NB. this repo is not replicating the bug.
In our real app we have many accordions that cause elements to be offscreen, so I think this could be related to the original issue I did point out.

I'm still unsure exactly which Svelte version has introduced the reactivity change, I will post more info later.

Reproduction

https://github.com/rallets/svelte-reactivity-issue

Logs

System Info

System:
    OS: Windows 11 10.0.26200
    CPU: (20) x64 12th Gen Intel(R) Core(TM) i7-12700H
    Memory: 31.45 GB / 63.68 GB
  Binaries:
    Node: 22.20.0 - C:\Program Files\nodejs\node.EXE
    npm: 11.6.2 - C:\Program Files\nodejs\npm.CMD
    pnpm: 10.14.0 - C:\Users\mauro\AppData\Roaming\npm\pnpm.CMD
  Browsers:
    Chrome: 142.0.7444.176
    Edge: Chromium (140.0.3485.54)
    Internet Explorer: 11.0.26100.1882
  npmPackages:
    svelte: 5.43.0 => 5.43.0

Severity

blocking an upgrade

[henrykrinkle01]

I mean you gain almost nothing but headache by upgrading Svelte since you don't use any of the new features.
So better stay at a stable version like 5.25.0 (don't remember exactly which one) where async hasn't been introduced.
That's what I do for my important apps that are in production. I only toy with experimental features in dev mode

[rallets]

Thanks for your explanation, I was not aware of the current codebase situation. Is it documented somewhere that Svelte has experimental releases using "stable" versioning?

I mean that it's not marked as 5.45.2.alpha/beta/experimental/unstable like rolldown is doing (f. ex. 1.0.0-beta.52).

How can someone be aware that is going to beta test experimental code? I think it's a pretty unusual way to release upgrades, and I think Svelte is not going to benefit from it. When you miss trust, it's pretty difficult to get it back.

I'm also using rolldown beta versions and had some bug related to multithreading (and in vite-plugin-svelte), but I was aware that a beta version could have some problems, and I do not blame devs to break things, but I'm happy to help testing beta stuff, where it doesn't break production apps.
I suggest to - at least - add come labels to the release notes (that I read before each upgrade).

I think that is best practice to stick the latest version available, because it's supposed to have the latest bug fixes, performance improvements and security patches.

[gterras]

Thanks for your explanation, I was not aware of the current codebase situation. Is it documented somewhere that Svelte has experimental releases using "stable" versioning?

They meant a functionally stable version (Svelte versioning being standard). This experimental flag was introduced because it was thought at the time this wouldn't leak into non-async codebase and would be a good enough solution, turns out it wasn't.

That's what I do for my important apps that are in production

We also do this, our biggest app is still in latest Svelte4 for the same reasons (we planned to upgrade when the new reactivity system dust was settled, which kind of never happened since the async changes triggered another round).

A compromise could be adopting Nodejs odd versioning, where say Svelte6 focuses on stability and Svelte7 brings all the experimental stuff. This would give more visibility and ease of use than a dedicated side branch.

A more robust and powerful way of approaching testing is I think also needed for the project because it has reached a scope where humans are strictly not able to foresee all the consequences of even small changes. Regressions are now a common habit of Svelte mainly because of this. Users doing quality control is now the default pipeline. LLMs could play a role in defining richer test suites and catch at least a part of it.

[dummdidumm]

Sorry for the caused pain - any code change, regardless of whether it's related to async or not can theoretically introduce a bug. We strive our best to avoid it.

NB. this repo is not replicating the bug.

Please provide a reproduction that does replicate the bug. It doesn't have to be minimal.