Parts of application infrequently broken after v5.43.12

[MathiasWP]

Describe the bug

This PR seems to have introduced something that breaks our app: #17191 (we checked every single version from v5.42.0)

I'm not sure what happens, but we have a table with multiple component. Clicking on the component causes it to toggle from "preview" to "input" mode, and when we do this enough times the components start freezing. Difficult to explain, but here's a video showing how it stops working:

Skjermopptak.2025-11-25.kl.15.26.05.mov

One last thing i have to get off my chest: I am starting to get trust-issues with Svelte upgrades. We have been affected 4 different times the last months due to upgrades coming from "async" mode, even though we have explicitly set FALSE in the experimental config. I know it's a lot of work to maintain a frontend library of this size, and i understand that you have a lot on your plate, but i just have to mention that the current state of feature flagging an experimental feature has not lived up to the expectations i have of this amazing framework/team. The bugs that have occurred the past months have been hard to spot, and there's almost no way for us to notice them except from receiving tickets from our users or us randomly stumbling across them while using our app.

As a result of this we have to reduce the frequency of updating Svelte (probably a good idea anyway in these Shai Hulud times), but now we're also going to be a little nervous when updating Svelte, which is a feeling i wish we didn't need to have.

I'm not hating, i am so grateful for the work you're putting into this framework. But i feel that this just has to be said - because it's almost starting a "should we migrate to another framework" discussion at work.

Quote from my co-worker: "async svelte has given us nothing but headaches, and we're not even using it!"

Reproduction

I'm not really sure how to repro this. It happens infrequently, and i'm not sure what in our code causes the error. But maybe this is somewhat relevant: #17201

Logs

System Info

System:
    OS: macOS 15.6.1
    CPU: (8) arm64 Apple M1 Pro
    Memory: 537.53 MB / 16.00 GB
    Shell: 5.9 - /bin/zsh
  Binaries:
    Node: 22.14.0 - /Users/mathiaspicker/.nvm/versions/node/v22.14.0/bin/node
    npm: 10.9.2 - /Users/mathiaspicker/.nvm/versions/node/v22.14.0/bin/npm
    pnpm: 10.22.0 - /opt/homebrew/bin/pnpm
    bun: 1.0.0 - /Users/mathiaspicker/.bun/bin/bun
  Browsers:
    Brave Browser: 142.1.84.139
    Chrome: 142.0.7444.176
    Edge: 142.0.3595.94
    Firefox: 142.0.1
    Safari: 18.6
  npmPackages:
    svelte: 5.43.12 => 5.43.12

Severity

blocking an upgrade

[henrykrinkle01]

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.

[dummdidumm]

I'm very sorry about the situation and we strive to do better than this.

In your video/reproduction, does each update create a new item in the list and "replace" the old one or are the items themselves stable and only their content changes?
A reproduction repository (doesn't have to be minimal) would be appreciated.

[MathiasWP]

I'm very sorry about the situation and we strive to do better than this.

In your video/reproduction, does each update create a new item in the list and "replace" the old one or are the items themselves stable and only their content changes? A reproduction repository (doesn't have to be minimal) would be appreciated.

This specific component looks like this:

<script lang="ts">
	import type { QuantityValueDto, UnitDto } from 'application/models/concepts/ConceptsModel';
	import type { State } from '../DataPointWrapper.svelte';
	import EditableInputWrapper from '../EditableInputWrapper.svelte';
	import QuantityTypeInput from '../inputs/QuantityTypeInput.svelte';
	import QuantityTypePreview from '../previews/QuantityTypePreview.svelte';

	type Props = {
		magnitudeValue: number | null;
		unit: UnitDto;
		editState: State;
		editable: boolean;
		save: (value: QuantityValueDto) => Promise<State>;
		cancel: () => void;
		clear: () => Promise<State>;
		activateEditing: () => void;
	};

	const { magnitudeValue, unit, editState, editable, save, cancel, clear, activateEditing }: Props =
		$props();

	let latestMagnitudeValue: number | null = $derived(magnitudeValue);
	let focusOffset = $state(0);
	let anchorOffset = $state(0);

	async function handleSave(value: QuantityValueDto) {
		latestMagnitudeValue = value.magnitude.value;
		const response = await save(value);
		if (response === 'error') {
			latestMagnitudeValue = magnitudeValue;
		}
	}

	async function handleClear() {
		latestMagnitudeValue = null;
		const response = await clear();
		if (response === 'error') {
			latestMagnitudeValue = magnitudeValue;
		}
	}
</script>

{#if editable}
	{#if editState === 'active'}
		<QuantityTypeInput
			{anchorOffset}
			{cancel}
			clear={handleClear}
			{focusOffset}
			magnitudeValue={latestMagnitudeValue}
			save={handleSave}
			{unit}
		/>
	{:else}
		<EditableInputWrapper
			disabled={editState === 'saving'}
			onclick={() => {
				const selection = window.getSelection();
				if (selection) {
					anchorOffset = selection.anchorOffset;
					focusOffset = selection.focusOffset;
				}
				activateEditing();
			}}
		>
			<QuantityTypePreview magnitudeValue={latestMagnitudeValue} {unit} />
		</EditableInputWrapper>
	{/if}
{:else}
	<QuantityTypePreview magnitudeValue={latestMagnitudeValue} {unit} />
{/if}

We have logged the code, and the onclick handler on the EditableInputWrapper runs when the component is "frozen", and it logs editState as active, but the UI is not updated. Also HMR in local development is broken when this "freeze" happens - it almost feels like the component becomes "disconnected".

[dummdidumm]

Yes it definitely looks like it's disconnected, which is also the problem of #17201 - I asked "does the array itself change" to understand if it is related to the linking that happens. I.e. is save causing a new instance of the array, or is it only modifying properties of an entry?

[MathiasWP]

Yes it definitely looks like it's disconnected, which is also the problem of #17201 - I asked "does the array itself change" to understand if it is related to the linking that happens. I.e. is save causing a new instance of the array, or is it only modifying properties of an entry?

save is updating the editState enum, but it's also triggering an onUpdate callback which sends a request to our backend. This will then cause an update on the source for this state, and looking at the flow for this exact component it looks like a new instance of the array is created, since there is a derived call that creates a new array every time the source changes (since it gets the whole new array from our backend):

// This is how the source for this component changes when `save` is called
const { config, warnings } = $derived(
	dataTableLayout.createColumnConfig({
		viewDataViewModels,
		querySubGroupingKeys,
		getComponentForAttribute: (attribute, entry, readonly) =>
			getComponentForAttribute({ attribute, entry, readonly, currentWorkspace })
	})
);

[gyzerok]

One last thing i have to get off my chest: I am starting to get trust-issues with Svelte upgrades. We have been affected 4 different times the last months due to upgrades coming from "async" mode, even though we have explicitly set FALSE in the experimental config. I know it's a lot of work to maintain a frontend library of this size, and i understand that you have a lot on your plate, but i just have to mention that the current state of feature flagging an experimental feature has not lived up to the expectations i have of this amazing framework/team. The bugs that have occurred the past months have been hard to spot, and there's almost no way for us to notice them except from receiving tickets from our users or us randomly stumbling across them while using our app.

As a result of this we have to reduce the frequency of updating Svelte (probably a good idea anyway in these Shai Hulud times), but now we're also going to be a little nervous when updating Svelte, which is a feeling i wish we didn't need to have.

I'm not hating, i am so grateful for the work you're putting into this framework. But i feel that this just has to be said - because it's almost starting a "should we migrate to another framework" discussion at work.

Quote from my co-worker: "async svelte has given us nothing but headaches, and we're not even using it!"

For us it was especially hard during the summer, when we had to live on some broken versions blocked from both upgrading and downgrading. So I can definitely relate to what you are saying here. I even created a discussion back then mentioning stability issues.

On the other hand Svelte team was nothing but responsive to the problems and helping us a lot in diagnosing and fixing them. Another good thing - with quite extensive test suite that Svelte has it doesn't feel like we hit same bugs often (if ever). And the more new ones and repros we discover the tighter this suit gets.

And as I see Svelte team being committed to acknowledging and fixing problems, I am as committed to update, find those problems and bring them to attention (as opposed to silently reverting back).

Also I feel like there is some room for improvement. Maybe it could be some rc versions, when bigger refactorings happen. Some heavy users could run them a bit in advance to see what's up. Maybe we need to have some channel on Discord between us to coordinate on the problems and on finding reproductions (cause that's usually the most difficult part). Maybe something else?

P.S.: Perhaps this discussion should happen elsewhere, just wanted to cheer up @MathiasWP a bit :)

[henrykrinkle01]

We do have a Discord channel for the experimental async stuff: https://discord.com/channels/457912077277855764/1420465980319989901

[dummdidumm]

@MathiasWP can you check if this still happens with the latest version?

[dummdidumm]

@MathiasWP can you check if this still happens with the latest version?

[MathiasWP]

@MathiasWP can you check if this still happens with the latest version?

Issue is still there on the latest version. Let me know if there's anything i can do to assist in solving this.

[dummdidumm]

Any kind of runnable reproduction would be great, doesn't have to minimal

[dummdidumm]

I think the bug is about effect.last not staying properly up to date:

1. list is created initially
2. new item is added somewhere in the middle. each_block_effect.last (no real variable name but describes what it is; the each block effect) is now that new item, but each_item.prev will be the previous item
3. during reconcile the linking sees "oh this newly added item's effect is the last one, let's change the next item's effect to be the new last one"
4. reconcile sees that the rest of the array stays the same, so it does not call link anymore
5. --> at this point each_block_effect.last is wrong

At this point it's wrong and I suspect that at some point this causes trouble by having parts of the graph not be connected properly anymore.