Derived value is not reactive when used in an `else if` branch.

[pauldemarco]

Describe the bug

A derived value that is within a svelte.ts class is not reactive when used in an else if branch.

Reproduction

Fully Reproducing REPL

Logs

No response

System Info

I also tried this branch to no avail: #13153

  System:
    OS: Linux 6.8 Ubuntu 22.04.4 LTS 22.04.4 LTS (Jammy Jellyfish)
    CPU: (24) x64 12th Gen Intel(R) Core(TM) i9-12900K
    Memory: 53.61 GB / 62.54 GB
    Container: Yes
    Shell: 5.1.16 - /bin/bash
  Binaries:
    Node: 22.6.0 - ~/.nvm/versions/node/v22.6.0/bin/node
    Yarn: 1.22.19 - /usr/local/bin/yarn
    npm: 10.8.2 - ~/.nvm/versions/node/v22.6.0/bin/npm
    pnpm: 9.1.4 - ~/.local/share/pnpm/pnpm
    bun: 1.0.0 - /usr/local/bin/bun
  Browsers:
    Brave Browser: 110.1.48.171
    Chrome: 128.0.6613.119
  npmPackages:
    svelte: https://gitpkg.now.sh/sveltejs/svelte/packages/svelte?fix-graph-inconsistency => 5.0.0-next.244 

### Severity

blocking all usage of svelte

[brunnerh]

Interestingly, adding an $inspect('busy', job.isBusy); also fixes it.
REPL

[pauldemarco]

Interestingly, adding an $inspect('busy', job.isBusy); also fixes it. REPL

True! We’ve got a Schrödinger’s situation here!
There were a couple cases where if I force it to show somewhere it would magically start working everywhere.

This “inspect” trick didn’t work for me in production, I’m assuming these calls are stripped out.

[brunnerh]

This “inspect” trick didn’t work for me in production, I’m assuming these calls are stripped out.

Correct, it's a dev feature.

By the way, there's a neat term for bug behavior like this: Heisenbug

[pauldemarco]

Here’s a wild guess without having looked under the hood of svelte 5:
Perhaps $derived only fires if it has a subscriber, and since the else if branch is not reached on initial render, the read from $derived doesn’t happen, therefore leading to no subscriber and broken reactivity when it does finally reach that branch?

[brunnerh]

That was my suspicion, but this works fine for every simplified reproduction that I tried, e.g..
The else if should always be reevaluated when the condition in the previous branch changes to false.

[pauldemarco]

That was my suspicion, but this works fine for every simplified reproduction that I tried, e.g.. The else if should always be reevaluated when the condition in the previous branch changes to false.

I wonder what might be different between our examples that’s causing mine to break. Perhaps it’s the nested async call?

[paoloricciuti]

Sorry can you help me understand what's the expected behaviour here? If i remove the if/else and add the separate if i see the same thing and trying to follow the code it seems also what i would expect to see...but maybe i'm missing something.

[brunnerh]

I wonder what might be different between our examples that’s causing mine to break.

Figured that out for the most part:
It's about how/where the class is created.

As far as I know, $derived are coupled to effects. Since you create the jobs in an asynchronous callback, there might be ownership issues (i.e. it might be coupled to the wrong parent effect).

Modified original REPL showing the difference by adding jobs on init.
My REPL, modified to set the job async.

[brunnerh]

@paoloricciuti Output is stuck showing Busy, though the $derived value under the hood should be false.

[7nik]

This the smallest REPL I got.

The derived gets stuck in MAYBE_DIRTY state.
I lean toward thinking that some promise race happens.

[paoloricciuti]

Mh, very weird quirk...if we start the retry before the first one have a chance to update the status it works.

[7nik]

Here is nothing more to delete

[pauldemarco]

Mh, very weird quirk...if we start the retry before the first one have a chance to update the status it works.

Nice find. Just a reminder that promoting the else if to a top level if also fixes it: REPL

[7nik]

Mh, very weird quirk...

That delay changes the change order from running -> failed -> running -> completed to running -> running -> failed -> completed.

Something wrong happens when the unowned derived detaches or re-attaches.

[7nik]

Completely another example.