fix: re-enable warning for reactivity loss after await #17364
Conversation
🦋 Changeset detectedLatest commit: bdde972 The changes in this PR will be included in the next version bump. This PR includes changesets to release 1 package
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 |
|
RazinShafayet2007
force-pushed
the
fix/async-reactivity-warning
branch
2 times, most recently
from
11d2693 to
d75681f
Compare
RazinShafayet2007
force-pushed
the
fix/async-reactivity-warning
branch
from
d75681f to
4a93f38
Compare
| if (current_async_effect) { | ||
| var tracking = (current_async_effect.f & REACTION_IS_UPDATING) !== 0; | ||
| var was_read = current_async_effect.deps?.includes(signal); | ||
|
|
||
| if (!tracking && !untracking && !was_read) { | ||
| w.await_reactivity_loss(/** @type {string} */ (signal.label)); | ||
|
|
||
| var stack_trace = get_error('traced at'); | ||
| // eslint-disable-next-line no-console | ||
| if (stack_trace) console.warn(stack_trace); | ||
| } | ||
| } |
There was a problem hiding this comment.
I think you missed one part of the TODO. It was not working properly before, so just uncommenting it will not make it work correctly no?
There was a problem hiding this comment.
Thanks for the heads up! I dug into the runtime code, and since .includes is syntactically valid here, I suspect the original issue was about reference equality (e.g. comparing a signal wrapper against a raw node causing false negatives). If that's the case, I can switch to .some() to check properly. Does that sound like the right fix?
There was a problem hiding this comment.
I don't have much insight on why this was commented but I suspect if the problem was just a reference equality it would've been fixed instead of commented. What I would do is git blame it, go check the pr that introduce it and try to understand why it was commented (possibly even asking whoever introduced it if it's not clear from the pr) and move on from there. Thanks for the effort 🤟🏻
There was a problem hiding this comment.
That makes total sense. I'll check the git blame history to track down the original PR and understand the context for why it was disabled. Thanks for the tip! I'll report back with what I find. 🤜🤛
2 participants
Description
In Svelte 5, reading state after an
awaitcauses silent reactivity loss. The function resumes execution without tracking context, so the UI simply fails to update without any feedback.This PR re-enables the
await_reactivity_losswarning inruntime.js. It now correctly detects when execution resumes after an await and warns the user if they try to read a signal, preventing hard-to-debug "silent failures."Verification
experimental: { async: true }).$statevariable after anawait.[svelte] await_reactivity_loss: Detected reactivity loss when reading...Before submitting the PR, please make sure you do the following
feat:,fix:,chore:, ordocs:.packages/svelte/src, add a changeset (npx changeset).Tests and linting
pnpm testand lint the project withpnpm lint