🦋 Changeset detected

Latest commit: 184b86f

The changes in this PR will be included in the next version bump.

Not sure what this means? Click here to learn what changesets are.

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

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

Playground

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

Still trying to wrap my head around the right way to think about this problem. But the more I think about it the more I think get_latest_async_batch isn't the right logic, and this example shows why:

• main
• this PR

When we use the most recent batch for the template effect, instead of the batch in which it was created, we see tearing (the first occurrence of {b} updates after the the second).

So this approach gets rid of one form of tearing (between {await push(count)} and {count} but in the process introduces another.

Thinking aloud time:

This is a lightly-tweaked version of the test in this PR, minus the boundary (which I don't think is relevant to the problem we're trying to solve).

If we press 'increment' twice then 'pop', the sequence of events is this:

1. batch 1 is created on mount and immediately resolves
2. batch 2 is created with count++ and other++, and does not resolve because of await push(count)
3. batch 3 is created with count++, and is blocked on batch 2 because it overlaps (with count) but is not a superset (because of other)
4. the await push(count) promise created in batch 3 resolves with 2, the current value of count
5. batch 3 is processed, but is blocked on batch 2
6. the await push(count) promise belonging to batch 2 also resolves, also with 2, because of the d.resolve(value) in deriveds.js
7. as a result of that promise resolving, the template effect is created (in the context of batch 2, which I think is correct), and {await push(count)} {count} {other} is rendered as 2 1 1 (which is clearly incorrect)
8. batch 2 is processed, and it resolves which means the newly created template effect is appended to the DOM
9. during batch.#commit, we rebase the resolved batch onto subsequent batches, by identifying any async deriveds that need to re-run. For reasons I don't fully understand, await push(count) is included in that set (I would expect it to be equal between batches 2 and 3). We therefore run that async effect again, which causes batch 3 to become pending once more
10. after rebasing, we see if there are any batches that are now unblocked. had we not just triggered a re-run of the async effect, that would include batch 3, but instead it remains pending while the torn result of batch 2 is rendered

In this case it would be sufficient to fix 9 such that the async effect doesn't re-run. But I suspect that would still result in buggy behaviour in other cases. Ultimately I think we need to fix 7. This PR does so by creating the template effect in the context of batch 3, but as explained above I don't think that's quite right. Maybe this is a case where batch 2 needs to wait until batch 3 is ready (similar to #17872). Or maybe we need to rethink blocking: instead of only resolving batch 3 once its blockers have completed, we apply batch 3's values onto its blockers and then discard it?

The journey continues.

Yes blocking needs more thought. I'm not sure if it's a series of tweaks or if we need to rethink how blocking works in general. E.g. another thing I found:
Batch C could be a superset of batch B, and then when it resolves just apply itself directly. But that could be wrong if batch B is blocked by batch A, which could also block C. i.e. we need some kind of "inherit blockers" logic.

I'm also not sure if the current blocking mechanism finds all types of correct blockers, or if some could be false positives. e.g. what if batch B will destroy the sources of batch A that are different to it (and therefore B thinks it needs to wait for A but it doesn't need to).

... which all makes me wonder if finding blockers through the reactivity graph (similar to how I try to entangle in #17872) could be another avenue.

Note to self: an example of the situation above could be

• a: {foo, bar}
• b: {foo, baz}
• c: {foo, baz, qux}

(Actually is that right? c would also be blocked by a in that example.)

yes I noticed that, too, and now I'm not sure why it would happen. But it definitely helps fix the bug described in sveltejs/kit#15431. I'll have to investigate more.

With the changes in main, in your "lightly-tweaked version"-playground, the batches now correctly resolve in order. The UI shows 1 1 1 as the end result though. Not sure why this happens for {count} yet but for {await push(count)} it's because batch 3 resolves the async before batch 2, and so the later values is set on the signal earlier than the earlier value. As a result count.v is 1.