fix(scheduler): job ordering when the post queue is flushing

[skirtles-code]

There are a couple of places where the scheduler has logic like this:

start = isFlushing ? flushIndex + 1 : 0

But there's a problem with how flushJobs resets these variables:

core/packages/runtime-core/src/scheduler.ts

Lines 258 to 264 in 29de6f8

	flushIndex = 0
	queue.length = 0
	flushPostFlushCbs(seen)
	isFlushing = false
	currentFlushPromise = null

The problem is that while flushPostFlushCbs(seen) is running, isFlushing will still be true, but flushIndex will be 0. That leads to the value of start being 1, when it should be 0.

Here's an example that shows this in action:

• Playground - 3.5.10

When clicking the button, notice that rendering runs before the pre watcher. This is because findInsertionIndex starts the binary search at 1, instead of 0.

Here's the same example, but using this PR:

• Playground - this PR

The other place that uses similar logic is flushPreFlushCbs. It's much more difficult to hit that one, as the post queue isn't usually running when flushPreFlushCbs is called, but it can happen via a nested call to mount() inside a post job.

---

The main idea behind the fix is to use -1 rather than 0 for flushIndex when the queue isn't currently flushing. The result is that the 'next job' is always flushIndex + 1, irrespective of whether the queue is currently running. So code like this:

start = isFlushing ? flushIndex + 1 : 0

... simplifies down to:

start = flushIndex + 1

With this change made, there's no longer any need to have a separate isFlushing flag, so I merged it into isFlushPending. But once those two flags are merged, the new flag is essentially just a boolean version of currentFlushPromise. So I removed both isFlushing and isFlushPending, just using currentFlushPromise in their place.

That all shaved a few extra bytes off the build and reduced the complexity of the scheduler a little.

---

When I first opened this PR it also included a change that moved the line currentFlushPromise = null to the end of flushJobs. I still think that's more correct, but it breaks the tests for radix-vue, so I've reverted that part of the change.

[github-actions]

Size Report

Bundles

File	Size	Gzip	Brotli
runtime-dom.global.prod.js	101 kB (-48 B)	38 kB (-50 B)	34.2 kB (-46 B)
vue.global.prod.js	160 kB (-48 B)	57.9 kB (-29 B)	51.5 kB (-19 B)

Usages

Name	Size	Gzip	Brotli
createApp (CAPI only)	49 kB (-48 B)	18.9 kB (-23 B)	17.2 kB (-4 B)
createApp	55.6 kB (-48 B)	21.4 kB (-35 B)	19.5 kB (-114 B)
createSSRApp	59.6 kB (-48 B)	23.1 kB (-26 B)	21.1 kB (+42 B)
defineCustomElement	60.4 kB (-48 B)	22.9 kB (-24 B)	20.9 kB (-27 B)
overall	69.3 kB (-48 B)	26.5 kB (-34 B)	24.1 kB (+24 B)

[pkg-pr-new]

Open in Stackblitz

@vue/compiler-core

pnpm add https://pkg.pr.new/@vue/compiler-core@12090

@vue/compiler-dom

pnpm add https://pkg.pr.new/@vue/compiler-dom@12090

@vue/compiler-ssr

pnpm add https://pkg.pr.new/@vue/compiler-ssr@12090

@vue/reactivity

pnpm add https://pkg.pr.new/@vue/reactivity@12090

@vue/compiler-sfc

pnpm add https://pkg.pr.new/@vue/compiler-sfc@12090

@vue/runtime-dom

pnpm add https://pkg.pr.new/@vue/runtime-dom@12090

@vue/runtime-core

pnpm add https://pkg.pr.new/@vue/runtime-core@12090

@vue/shared

pnpm add https://pkg.pr.new/@vue/shared@12090

@vue/server-renderer

pnpm add https://pkg.pr.new/@vue/server-renderer@12090

@vue/compat

pnpm add https://pkg.pr.new/@vue/compat@12090

vue

pnpm add https://pkg.pr.new/vue@12090

commit: fe637aa

[edison1105]

/ecosystem-ci run

[vue-bot]

📝 Ran ecosystem CI: Open

suite	result	latest scheduled
language-tools	❌ failure	❌ failure
nuxt	✅ success	✅ success
pinia	✅ success	✅ success
primevue	✅ success	✅ success
quasar	✅ success	✅ success
radix-vue	❌ failure	✅ success
router	✅ success	✅ success
test-utils	✅ success	✅ success
vant	✅ success	✅ success
vite-plugin-vue	✅ success	✅ success
vitepress	✅ success	✅ success
vue-i18n	✅ success	✅ success
vue-macros	✅ success	❌ failure
vuetify	✅ success	✅ success
vueuse	✅ success	✅ success
vue-simple-compiler	✅ success	✅ success

[edison1105]

/ecosystem-ci run radix-vue

[vue-bot]

📝 Ran ecosystem CI: Open

suite	result	latest scheduled
radix-vue	❌ failure	✅ success

[skirtles-code]

Seems that radix-vue test is failing consistently. I'll try to investigate locally...

[edison1105]

/ecosystem-ci run

[skirtles-code]

The radix-vue test failure seems to be caused by my change to nextTick, so I've reverted that part for now as it isn't strictly necessary for the rest of the fix. I still believe my change to nextTick was a step in the right direction, but the Combobox in radix-vue has some interesting uses of nextTick that make it sensitive to any change:

https://github.com/radix-vue/radix-vue/blob/8578dc9ecf34439cb05b96c7ce2e295477f3374c/packages/radix-vue/src/Combobox/ComboboxRoot.vue#L213-L228

[vue-bot]

📝 Ran ecosystem CI: Open

suite	result	latest scheduled
language-tools	❌ failure	❌ failure
nuxt	✅ success	✅ success
pinia	✅ success	✅ success
primevue	✅ success	✅ success
quasar	✅ success	✅ success
radix-vue	✅ success	✅ success
router	✅ success	✅ success
test-utils	✅ success	✅ success
vant	✅ success	✅ success
vite-plugin-vue	✅ success	✅ success
vitepress	✅ success	✅ success
vue-i18n	✅ success	✅ success
vue-macros	✅ success	❌ failure
vuetify	✅ success	✅ success
vueuse	✅ success	✅ success
vue-simple-compiler	✅ success	✅ success