What does it mean when $inspect.trace shows no source for the trigger?

[jakubsmolaga]

Hi, first of all sorry for no reproducible example but I've only been able to capture this behavior in the project I'm working on which I'm sadly not able to share. Basically I noticed that a lot of derived values are being recalculated a lot more than expected. I started using $inspect.trace to find the issues. Generally speaking, the root cause of the recalculation was usually highlighted in the produced log. With that I was able to fix some issues including the fact that apparently if ('someKey' in someObj) { /* ... */ } will re-trigger even if the keys of someObj doesn't change - updating someObj.someKey = /* ... */ also triggers a recalculation but I was able to fix that with untrack. At some point I hit a wall, all the extra recalculations I have now do not highlight any particular state variable in the output of $inspect.trace. How am I supposed to interpret that? Does that mean that the derived value got recalculated for no reason? Sorry for rambling but I have a tight deadline for this project and I'm getting really stressed out by not being able to get Svelte to do what I want it to do. I just want to know if this is normal behavior and if so, how am I supposed to interpret it? Thanks :)

[mg1986jp]

When $inspect.trace shows a recalculation with no highlighted source, it usually means the derived was invalidated by a dependency that itself is a derived — the trace shows the immediate trigger, but if that trigger is a derived that was already re-evaluated (and its value didn't actually change), the trace can't point to a specific state variable.

Two common causes in practice:

1. Fine-grained reactivity loss through object spreading or destructuring

If you have something like:

let derived1 = $derived({ ...someStore, extra: computed });
let derived2 = $derived(doSomething(derived1));

Every time derived1 runs, it creates a new object reference even if the contents are identical. derived2 sees a "new" dependency and re-runs. The trace won't show a specific state var because the trigger is derived1 itself, not a state.

Fix: make derived1 return the same reference when nothing changed, or make derived2 depend on specific properties instead of the whole object.

2. The in operator issue you found is part of a bigger pattern

in reads the keys of a reactive proxy, which means any mutation to the object (even unrelated keys) triggers a re-read. Same thing happens with Object.keys(), Object.entries(), JSON.stringify(), or spreading {...obj} on a reactive object. All of these read the full key set, so any property change on the object triggers recalculation.

If you can share even a simplified version of the dependency chain (derived A depends on derived B depends on state C), I can probably spot where the spurious invalidation is coming from. The pattern is almost always: somewhere in the chain, a derived creates a new reference without the value actually changing.

[jakubsmolaga]

Thank you for both your answers, they're both very helpful. I started reading the source code to get a better understanding and from what I understand the in operator works slightly differently than what you @mg1986jp described (although I might just be wrong 😄). Object.keys will call call ownKeys trap on the proxy which will subscribe to the version of the object which in fact gets updated whenever keys change just as you described. The in operator on the other hand calls has trap on the proxy which actually from my understanding subscribes to the value of that particular property, This is how the source gets created in the has trap:

	s = with_parent(() => {
		var p = has ? proxy(target[prop]) : UNINITIALIZED;
		var s = source(p, stack);

		if (DEV) {
			tag(s, get_label(path, prop));
		}

		return s;
	});

I suppose this is a compromise of some sort. If it subscribed to the version it would get triggered any time any property gets added or removed which could be bad in some use-cases, but in the current implementation it triggers on every change to the value of the property even if the keys never change which is extremely bad for my use-case. Neither is prefect but I find it hard to believe that the first problem (where the list of keys changes a lot) happens more often than the second one (where we have an object with stable keys and are modifying the values a lot) but I might be missing something since I just looked at the code-base for the first time and I'm not the sharpest tool in the shed. It would be awesome if some maintainer (or maybe even @Rich-Harris himself 😛) gave some reasoning for this decision but I might be asking for too much 😄.

Anyway, thanks for all your help, it actually explained quite a lot about what's going on in my code-base. I still haven't fully solved the mystery of missing dependencies but now I at least know what to look for with the help of your answers.

[jakubsmolaga]

I made the following change in my local node_modules and it seems to work fine but I don't know if it could be silently breaking something I don't know about.

--- a/packages/svelte/src/internal/client/proxy.js
+++ b/packages/svelte/src/internal/client/proxy.js
@@ -226,34 +226,10 @@ export function proxy(value) {
                                return true;
                        }

+                       get(version);
                        var s = sources.get(prop);
                        var has = (s !== undefined && s.v !== UNINITIALIZED) || Reflect.has(target, prop);

-                       if (
-                               s !== undefined ||
-                               (active_effect !== null && (!has || get_descriptor(target, prop)?.writable))
-                       ) {
-                               if (s === undefined) {
-                                       s = with_parent(() => {
-                                               var p = has ? proxy(target[prop]) : UNINITIALIZED;
-                                               var s = source(p, stack);
-
-                                               if (DEV) {
-                                                       tag(s, get_label(path, prop));
-                                               }
-
-                                               return s;
-                                       });
-
-                                       sources.set(prop, s);
-                               }
-
-                               var value = get(s);
-                               if (value === UNINITIALIZED) {
-                                       return false;
-                               }
-                       }
-
                        return has;
                },

[mg1986jp]

@jakubsmolaga Yeah I mixed up has and ownKeys, my bad. You're right — ownKeys subscribes to version (key add/remove only), but has creates a per-property source and calls get(s) on it, so it tracks the value, not just key existence. Totally different behavior.

I looked at the actual has trap in proxy.js and your reading is correct:

// has trap creates/gets a source for the property, then calls get(s)
// this subscribes to value changes, not just key existence
var value = get(s);
if (value === UNINITIALIZED) {
    return false;
}

Your patch looks safe to me. deleteProperty already calls increment(version), so key removal would still trigger re-evaluation through your get(version) read. The only edge case I'd double-check: does the set trap call increment(version) when a new key is added (not just updating an existing one)? If not, 'newKey' in obj wouldn't react to a newly added property. Worth verifying before you open an issue.

Open an issue with this — I'd want to hear from the maintainers on whether the current has behavior is intentional. Your use case (stable keys, frequently changing values) seems common enough that it shouldn't require untrack workarounds.

[jakubsmolaga]

I opened an issue as you suggested. I hope I at least learn something new from it 😄

[Nic-Polumeyv]

The patch shouldn't silently break anything, deletes and new keys both bump version so in can't go stale, the trade-off you described is the whole cost. #18306 is asking for in to be made fine grained, your findings are good evidence there.

For the trace, the blue highlight just means that dep was written since the reaction's last run. No highlight anywhere means no dep changed at all, the scheduler re-ran your derived for its own reasons. The earlier comment has that part backwards by the way, derived deps are logged recursively and highlighted like everything else. Are you on experimental.async? Deriveds rerunning with no dirty deps is a known bug there, #18503, and if you're not on async this is worth an issue on its own.