fix: don't revert source to UNINITIALIZED state when time travelling

[Rich-Harris]

This is an alternative to #17373, and fixes #17271. (The other PR does not fix the bug, unfortunately.)

I say 'partially' because it still fails when hydrating; in that case, effects that are created before an await is encountered run too soon. They should run once the component and all its children have finished doing whatever they need to do. As yet I haven't quite managed to figure out how to express that in code.

This PR brings over the test from #17373 and adjusts it such that it fails on both main and that PR.

Before submitting the PR, please make sure you do the following

• It's really useful if your PR references an issue where it is discussed ahead of time. In many cases, features are absent for a reason. For large changes, please create an RFC: https://github.com/sveltejs/rfcs
• Prefix your PR title with feat:, fix:, chore:, or docs:.
• This message body should clearly illustrate what problems it solves.
• Ideally, include a test that fails without this PR but passes with it.
• If this PR changes code within packages/svelte/src, add a changeset (npx changeset).

Tests and linting

• Run the tests with pnpm test and lint the project with pnpm lint

[changeset-bot]

🦋 Changeset detected

Latest commit: 495f581

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

This PR includes changesets to release 1 package

Name	Type
svelte	Patch

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

[github-actions]

Playground

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

[dummdidumm]

I don't quite understand why we need this special case. If something is only getting initialized within a batch why not revert to uninitialized outside it? Wouldn't that mean the value is wrongfully bleeding into other batches while this one isn't committed yet?

[Rich-Harris]

The point of this.previous is that if batch B is created while batch A is ongoing, we can commit batch B without the changes in batch A from being erroneously applied.

But in this scenario, the value hasn't changed — it was being initialized in batch A. It wouldn't make sense to revert it to an uninitialized state

[elliott-with-the-longest-name-on-github]

I don't fully understand this but the test looks legit, so...