fix: ignore false-positive errors of $inspect dependencies#18106
Conversation
We had logic in place to ignore errors of `$inspect` effects that are about to destroy, but we didn't take into account that we can get these transient errors while checking for `is_dirty` in preparation for running the effect, too. Now effects are marked as dirty in case an error occurs while evaluating their dependencies, which guarantees we will see the error again but we can then handle it properly. Fixes #15741
🦋 Changeset detectedLatest commit: 0e35bd8 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 |
|
|
The try/catch with |
While working on #18106 I noticed that we're not adding eager effects inside `mark_reactions` when `DEV` is `false`. As a result production build could have `$state.eager` or `$state.pending` not working correctly. No test because I can't get Vitest to not run with `DEV` being `true`.
While working on #18106 I noticed that we're not adding eager effects inside `mark_reactions` when `DEV` is `false`. As a result production build could have `$state.eager` or `$state.pending` not working correctly. ~No test because I can't get Vitest to not run with `DEV` being `true`.~ added a test
…e into eager-effects-derived-fix
|
@afurm there's no loop here that I can see, calling |
Rich-Harris
left a comment
There was a problem hiding this comment.
actually, rescinding my approval until I can better understand something — I found a case that's buggy in this PR. It's buggy on main too but differently:
|
pushed a fix, albeit without a test because I'm not quite sure how to write one for it |
This PR was opened by the [Changesets release](https://github.com/changesets/action) GitHub action. When you're ready to do a release, you can merge this and the packages will be published to npm automatically. If you're not ready to do a release yet, that's fine, whenever you add more changesets to main, this PR will be updated. # Releases ## svelte@5.55.6 ### Patch Changes - fix: leave stale promises to wait for a later resolution, instead of rejecting ([#18180](#18180)) - fix: keep dependencies of `$state.eager/pending` ([#18218](#18218)) - fix: reapply context after transforming error during SSR ([#18099](#18099)) - fix: don't rebase just-created batches ([#18117](#18117)) - chore: allow `null` for `pending` in typings ([#18201](#18201)) - fix: flush eager effects in production ([#18107](#18107)) - fix: rethrow error of failed iterable after calling `return()` ([#18169](#18169)) - fix: account for proxified instance when updating `bind:this` ([#18147](#18147)) - fix: ensure scheduled batch is flushed if not obsolete ([#18131](#18131)) - fix: resolve stale deriveds with latest value ([#18167](#18167)) - chore: remove unnecessary `increment_pending` calls ([#18183](#18183)) - fix: correctly compile component member expressions for SSR ([#18192](#18192)) - fix: reset `source.updated` stack traces after `flush` ([#18196](#18196)) - fix: replacing async 'blocking' strategy with 'merging' ([#18205](#18205)) - fix: allow `@debug` tags to reference awaited variables ([#18138](#18138)) - fix: re-run fallback props if dependencies update ([#18146](#18146)) - fix: abort running obsolete async branches ([#18118](#18118)) - fix: ignore comments when reading CSS values ([#18153](#18153)) - fix: wrap `Promise.all` in `save` during SSR ([#18178](#18178)) - fix: ignore false-positive errors of `$inspect` dependencies ([#18106](#18106)) Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
We had logic in place to ignore errors of
$inspecteffects that are about to destroy, but we didn't take into account that we can get these transient errors while checking foris_dirtyin preparation for running the effect, too. Now effects are marked as dirty in case an error occurs while evaluating their dependencies, which guarantees we will see the error again but we can then handle it properly.Fixes #15741