Repository navigation
Conversation
checkDirty() left the Pending flag set on the subscribers it was walking when a computed's getter threw, so later propagate() calls treated them as already queued and never notified them again. Also link the computed to the active subscriber even when the getter throws, otherwise endTracking() drops the dep on the first failing read.
|
Important Review skippedAuto reviews are disabled on base/target branches other than the default branch. Please check the settings in the CodeRabbit UI or the
 |
@vue/compiler-core
@vue/compiler-dom
@vue/compiler-sfc
@vue/compiler-ssr
@vue/compiler-vapor
@vue/reactivity
@vue/runtime-core
@vue/runtime-dom
@vue/runtime-vapor
@vue/server-renderer
@vue/shared
vue
@vue/compat
commit: |
Size ReportBundles
Usages
|
This branch has not been deployed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Once a watched computed's getter throws, the subscriber is dead for good: with
s = ref(0),c = computed(() => s.value === 1 ? throw : s.value)andwatch(c, cb), settingsto 1 throws as expected, but the later writess = 2ands = 3never reach the callback. 3.5.45 reports the error and keeps delivering2and3. The same happens for a plaineffect, for a chain of computeds, and for an effect with a custom scheduler (the script in the issue logs[0]instead of[0, 2, 3]).Two things go wrong.
checkDirty()insystem.tsrefreshes stale computeds in place, and when(dep as Computed).update()or the(sub as Computed).update()in the unwinding loop throws, the function is left through the exception with thePendingflag thatpropagate()set still on the subscriber and on every intermediate computed on the check chain; the nextpropagate()sees those flags, decides the node is already queued and neither notifies it nor descends into its own subscribers. Wrapping the walk intry/catchand clearingPendingonsub,link.suband the remaining stack entries before rethrowing restores the 3.5 behaviour — the failing step is lost, the error is reported, the following ones run. Separately,ComputedRefImpl.get value()incomputed.tscallslink()afterupdate(), so a subscriber that reads the computed insiderun()(custom scheduler, first render, first watch run) never records the dep andendTracking()unlinks it; the tracking block now sits in atry { … } finally { link(…) }so the link survives a throwing getter, which is whatdep.track()-before-evaluate gave us in 3.5.Catching inside the
effect.tsandcomputed.tsgetters instead would have been a smaller diff, but it cannot clear thePendingflag left on intermediate computeds, so the chained case stays broken. Sibling fix in the same area: ef5ff10 (#15676), which kept the rest of a batch notified when one subscriber throws.fix #16173