fix: correctly block on earlier batches

[dummdidumm]

This tweaks the async batch algorithm:

• If two batches touch distinct sources they can resolve independently (i.e. one started later can resolve earlier)
• If a later batch is a superset of an earlier one it can ignore it because we know it will do all the work the earlier one does
• Else if they overlap the later one is blocked on the earlier one

This also changes how batch_values is computed. During batch.#traverse we no longer use the previous values of earlier batches, in other words we see the latest value up to this batch. This is important to fix #17099, because the core problem of that bug is that when a later batch creates new effects with a previous value we have no good way to then update those effects after the earlier batch resolves (write versions are older for the earlier one).

But that means the blocking logic now also has to include new branches: If a later batch creates a new branch that then reads a value that an earlier batch wrote, we also have to block in that case, because we cannot show the new values of the earlier batch before that one has resolved.

It also includes logic of not outright rejecting earlier batches' promises once a later batch resolves in async_derived, because that batch might have other pending work that is either not superseeded by a later batch or will be superseeded by another batch. Instead we tell the batch which of its async work is obsolete, and if everything's obsolete we know we can savely discard it. This closes #17935 - I feel like a few more tests in that direction would be good though.

As a result batches resolve in the order they are started, if they are related, and the rebase algorithm becomes obsolete.

[changeset-bot]

⚠️ No Changeset found

Latest commit: 9fdcfe1

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

[github-actions]

Playground

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

[dummdidumm]

Found a case that works on main but not in this PR fixed

[Rich-Harris]

as far as I can see the sorting is unnecessary? the only thing we do with the resulting array is this:

Promise.all(blockers.map((b) => b.settled())).then(...);

Suggested change

	for (const batch of [...this.blockers].sort((a, b) => b.id - a.id)) {
	for (const batch of this.blockers) {

[svelte-docs-bot]

Preview: https://svelte-dev-git-preview-svelte-17971-svelte.vercel.app/