I've been running into this as a false positive when there are more than 1000 elements being rendered on the page that have some sort of common dependency, almost as if it's a false positive infinite loop guard.

For example, in Bits UI, the <Tooltip.Root> will derived some properties from a parent <Tooltip.Provider>, the following works fine:

<Tooltip.Provider>
	{#each { length: 999 } as i}
		<Tooltip.Root />
	{/each}
</Tooltip.Provider>

But as soon as you bump length to 1000 we get effect_update_depth_exceeded errors.

Thanks @huntabyte. This explains some of the intermittent issues I had while investigating effect_update_depth_exceeded.

When running the latest 5.37.3 I'm getting another error and assumed they were latest, but this appears to be 2 separate issues - false positive effect_update_depth_exceeded and another error UpdatedAtError.

Going to trace back the original version when UpdatedAtError started presenting.

Looks like the root issue (causing the application to lock) started in 3.36.0 (i.e. async edition), with UpdatedAtError logging added in 3.36.5. See LayerChart issue comment for more context.

Going to update the issue title to reflect the root issue (effect_update_depth_exceeded being a false postiive, new UpdatedAtError being the primary issue).

Once again, let me know if we're doing something unsupported in LayerChart.

Thanks again!

We have the exact same false positive bug with shadcn tooltip (which uses bits-ui under the hood). The false positive error is annoying, but the freezing it creates for seconds until the errors throw in the console is a problem.

Downgrading is not an option for us, since we had to upgrade to latest version yesterday to fix/workaround a sneaky bug in Firefox that breaks our app. I just removed the tooltips for now, hopefully it won't be triggered otherwise until svelte comes with a fix. Choosing my poison !

We are also experiencing this issue, by simply having a page that renders a lot of components, on hydration we see effect_update_depth_exceeded on versions later than 5.34.1. it seems like it's just when the amount of $effect reach 1000 not because they are recursive or illegal

Same here!

@techniq I'm unable to reproduce this in the latest version of Svelte. If this is reproduble for you still, please provide a reproduction repository with steps on how to reproduce.

@huntabyte I can reproduce this using your snippet, thanks.

@AndreasHald did you check with the latest version? There was a bugfix around deriveds and effects. If it's happening still, are those effects writing to state, and if yes what is that state changing?

Thanks @dummdidumm. I'm still able to reproduce using 5.38.1 on a LayerChart branch, but having trouble boiling it down to root cause. I'll keep poking around and see if a I can create a more minimal use case.

@dummdidumm the UpdatedAtError appears to be a "volume" issue as well

Rendering 10 instances of this chart doesn't produce any errors

<script lang="ts">
  import { Area, Axis, Chart, Layer } from 'layerchart';
  import { createDateSeries } from '$lib/utils/genData.js';

  const dateSeriesData = createDateSeries({ count: 30, min: 50, max: 100, value: 'integer' });
</script>

{#each { length: 10 } as _}
  <div class="h-[300px] p-4 border rounded-sm">
    <Chart
      data={dateSeriesData}
      x="date"
      y="value"
      yDomain={[0, null]}
      yNice
      padding={{ left: 16, bottom: 24 }}
    >
      <Layer type="svg">
        <Axis placement="left" grid rule />
        <Axis placement="bottom" rule />
        <Area line={{ class: 'stroke-2 stroke-primary' }} class="fill-primary/30" />
      </Layer>
    </Chart>
  </div>
{/each}

but rendering 11+ does...

If I remove a component such as Area or reduce the data and thus reducing the number of axis ticks/etc, the error goes away

I'll continue to work on a better reproduction, but wanted to share my findings in case its helpful. Thanks!

That's fine, this is already enough to confirm the issue. To clarify: do you also have any performance problems (like mentioned by the people using the bits-ui tooltip)?

I also ran into this issue using a bits-ui Combobox with the Combobox.Viewport Combobox.Item collection built using an {#each} block referencing a 1500-lengh array. Was on Svelte 5.38.1 and bits-ui 1.7.0.

Would be grateful if people in this thread could try out #16612 and #16623 to see if either/both fix this issue:

pnpm add https://pkg.pr.new/svelte@16612

pnpm add https://pkg.pr.new/svelte@16623

@Rich-Harris Not for me! I tried both on a data-table rendering about ~510 cells (each is a svelte component with multiple parts, and $derived runes). I don't have the infinite error, but there's a severe lag (page unresponsive) when i modify any state in the data-table component.

The issue does not exist in <5.35.4. I can't however pinpoint the issue.

The code did not change, only the svelte versions:

this is < 5.35.4

This is >= 5.35.4 (Page crashed after i stopped the recording)

How about this version?

pnpm add https://pkg.pr.new/svelte@f89e355

Context: #16623 (comment)

I have a page that would throw the effect_update_depth_exceeded error immediately from rendering a bunch of layerchart charts and all 3 changes (16612, 16623, and f89e355) each resolve the error for me.

Thanks @Rich-Harris! Tested all 3 versions and they all fixed UpdatedAtError and restored interactivity (tooltips) but have very noticeable performance regressions.

svelte@5.34.1 (baseline)

svelte@16612

svelte@16623

svelte@f89e355

at least when ran in dev / locally. I just tested svelte@f89e355 deployed and it is much more responsive, but still no where near 5.34.1 (including in dev)

svelte@f89e355

compared to 5.34.1 (deployed)

In short, all versions fixed the primary error, but do have performance regressions compared to 5.34.1, especially when ran in development.

@AndreasHald did you check with the latest version? There was a bugfix around deriveds and effects. If it's happening still, are those effects writing to state, and if yes what is that state changing?

Tested with 5.38.1and still get the error there. We sometimes do stuff like this where we sync props to client side only libraries

<script lang="ts">
let { disabled } = $props();
let someClientSideOnlyLibrary = $state();

onMount(() => {
   someClientSideOnlyLibrary = new SomeClientSideOnlyLibrary();
});

$effect(() => {
   if(disabled) {
      someClientSideOnlyLibrary.disable()
   } else {
      someClientSideOnlyLibrary.enable()
   }
})

</script>

or stuff like this

<script lang="ts">
let { value } = $props();
const _value = writable();

$effect(() => {
    _value.set(value)
})

</script>

I realise that the last example especially can be simplified with runes, but it takes us a little while in a large codebase to adopt them everywhere.

How about this version?

pnpm add https://pkg.pr.new/svelte@f89e355

Context: #16623 (comment)

Tested this one, it also resolved the error for us. I can't simulate the performance diff as well as @techniq but subjectively it does feel a tad slower.

I'm somewhat sure that the performance cliff is more noticeable after the "effect update depth exceeded" bug is resolved simply because the rendering actually finishes and doesn't abort beforehand.

Does this version change anything for y'all?

pnpm add https://pkg.pr.new/svelte@e11e381

Thanks @dummdidumm. svelte@e11e381 feels the same as the others.

@Rich-Harris @dummdidumm I would like to say generally for many use cases the performance feels good, and the force components have had a history with Svelte 5 performance regressions.

But I also noticed rendering all our BarChart examples does take 20+ seconds

and before (5.34.1) it was about 3 seconds

btw, I didn't catch this before, but svelte@16623 still throws some UpdatedAtError for at least a few of the force examples (but not for Area and many others that 5.38.1 was)

svelte@16612 doesn't appear to throw any that I've seen.

Tangential to the main point, but @AndreasHald does someClientSideOnlyLibrary need to be state?

<script lang="ts">
let { disabled } = $props();
let someClientSideOnlyLibrary = $state();

onMount(() => {
   someClientSideOnlyLibrary = new SomeClientSideOnlyLibrary();
});

$effect(() => {
   if(disabled) {
      someClientSideOnlyLibrary.disable()
   } else {
      someClientSideOnlyLibrary.enable()
   }
})

</script>

If this is representative of real code, I'm fairly sure you could use a normal variable...

let someClientSideOnlyLibrary = $state();
let someClientSideOnlyLibrary;

...in which case you wouldn't be setting state in an effect, which is the root of all these problems.

It doesn't - it should definitely just be a variable

Okay, spent a few hours debugging this today, mostly using the LayerChart site to test out hypotheses. It turns out there are two reasons 5.38.1 is slower than 5.35.3:

1. #16280 (which we knew about)
2. #16405 — we now attach stack traces to sources if they get updated during an effect, so that we can print useful diagnostic information if we end up in a loop. This only happens in dev, and is a much less significant factor than #16280 (and doesn't cause false positive infinite loop errors), so while it would be nice to fix it it's not a burning priority

In fact if you dig into node_modules and comment out the break here...

https://github.com/sveltejs/svelte/blob/7b2d7746277dae6372ed7b836ad895bde536dc89/packages/svelte/src/internal/client/reactivity/batch.js#L624-L630

...and this block...

https://github.com/sveltejs/svelte/blob/7b2d7746277dae6372ed7b836ad895bde536dc89/packages/svelte/src/internal/client/reactivity/sources.js#L187-L200

...things should run the same as they did in 5.35.3. For me at least, the force simulations are smooth as butter.

To recap: the reason for the big slowdown is that it's possible (though not easy!) to get yourself into a situation where object.property is read when object is falsy:

{#if object}
  <!-- this block could have an `object.property` reference that evaluates before the `if` is destroyed -->
{/if}

#16280 fixes this by aborting effect flushing if a state change occurs inside an effect. That turns out to be much too aggressive. @dummdidumm and I have been trying various ways to make it less so:

• #16612 traverses the effect tree when a state change occurs inside an effect, but only block effects. This helps (it fixes the errors), but still has some overhead because traversal isn't free
• #16623 tries to make the detection more accurate: it aborts, but only if an existing block effect is invalidated by another effect during the flush. This helps a lot (though we get a lot of false positives because 'block effect' also encompasses the effects that manage attributes on elements with spreads, so that we don't needlessly destroy unchanged attachments — long story) but doesn't fix the errors. It just makes you less likely to encounter them
• #16631 is the most recent attempt. This time around, we don't abort flushing, but if a block effect is rescheduled it jumps to the front of the queue. This allows everything to flush correctly but without constantly aborting and restarting

I'm reasonably optimistic about #16631, though I still have some question marks over it that I'll revisit later.

(As ever: if you're able to try out the pkg.pr.new link and report back, it would be very helpful! Thanks)

I really appreciate all the hard work @Rich-Harris (and @dummdidumm / team).

I can confirm running svelte@16631 in dev is substantially better than latest 5.38.1 (but not 5.34.1 level as expected) and does not generate any UpdatedAtError instances.

and svelte@16631 in prod is back to being buttery smooth 🏃‍♂️

Thanks!