fix(scheduler): prevent duplicate jobs being queued#11826
fix(scheduler): prevent duplicate jobs being queued#11826yyx990803 merged 1 commit intovuejs:mainfrom
Conversation
Size ReportBundles
Usages
|
@vue/compiler-core
@vue/compiler-dom
@vue/compiler-ssr
@vue/reactivity
@vue/compiler-sfc
@vue/runtime-core
@vue/runtime-dom
@vue/server-renderer
@vue/shared
@vue/compat
vue
commit: |
|
Great work, I'll get this released in a patch, let's follow up with a test case later. |
Even after upgrading to Vue 3.5.27, the same problem remains Uncaught (in promise) Maximum recursive updates exceeded in component <ElOnlyChild>. This means you have a reactive effect that is mutating its own dependencies and thus recursively triggering itself. Possible sources include component template, render function, updated hook or watcher source function. |
|
@jackchoumine That error message indicates excessive recursion during rendering. The most likely cause of that is a bug in your code, not a bug in Vue itself. The problem addressed by this PR was a specific edge case in early 3.5 releases. That problem is not present in 3.5.27. If you're having trouble finding where the problem lies then I suggest asking either on GitHub Discussions or the Vue Land Discord server. If you believe you've found a bug in Vue core then you'll need to open a new issue, with a reproduction. Thanks. |
Fixes #11712
Fixes #11807
I still need to write some tests for this, but the existing tests pass.
A job should only appear in the active part of the scheduler queue once. Currently it can be added multiple times, with the job being added again every time a reactive dependency changes.
The
QUEUEDflag should be set for all jobs that are currently in the queue, not just those with a particular value forALLOW_RECURSE.The
ALLOW_RECURSEflag is only relevant if a job is re-queued while that same job is currently running. Here I've implemented that by clearing the flagQUEUEDimmediately prior to running the job ifALLOW_RECURSEis set. Otherwise the flag is cleared after the job runs.It isn't clear to me how errors should be handled. For the main queue, I assume the
QUEUEDflags all need to be unset in thefinallyblock, as an error may have been thrown during flushing that prevented some of the flags being unset. For the post queue there doesn't seem to be equivalent error handling and I'm not sure if that should be added.