vitest-dev/vitest · error
Projects " " and " " have different 'maxWorkers' but same…
Error message
Projects "${last}" and "${spec.project.name}" have different 'maxWorkers' but same 'sequence.groupOrder'.\nProvide unique 'sequence.groupOrder' for them. What it means
When grouping specs by sequence.groupOrder, all projects sharing a groupOrder must have the same maxWorkers; otherwise the concurrency budget for that group is ambiguous and Vitest throws. The error names the conflicting projects so you can disambiguate their config.
Solutions
- Give each project a unique test.sequence.groupOrder value.
- Align test.maxWorkers across projects that share a groupOrder.
- Set groupOrder explicitly on every project rather than relying on the default 0.
Example fix
// before - both projects default groupOrder 0, different maxWorkers
export default defineProject(() => [
{ test: { name: 'a', maxWorkers: 4 } },
{ test: { name: 'b', maxWorkers: 1 } }
])
// after
export default defineProject(() => [
{ test: { name: 'a', maxWorkers: 4, sequence: { groupOrder: 1 } } },
{ test: { name: 'b', maxWorkers: 1, sequence: { groupOrder: 2 } } }
]) Defensive patterns
Strategy: validation
Validate before calling
function groupOrdersAreUniquePerMaxWorkers(projects) {
const byOrder = new Map()
for (const p of projects) {
const order = p.config.sequence?.groupOrder ?? 0
const mw = p.config.maxWorkers
if (byOrder.has(order) && byOrder.get(order) !== mw) return false
byOrder.set(order, mw)
}
return true
}
// before run: assert groupOrdersAreUniquePerMaxWorkers(vitest.projects) Prevention
- Assign an explicit, unique sequence.groupOrder to every project.
- When overriding maxWorkers on a project, also set a unique groupOrder.
- Document the groupOrder convention in the workspace README.
When it happens
Trigger: Two projects configured with the same sequence.groupOrder (default 0) but different resolved maxWorkers, encountered while building groups in the pool. The last spec already in the group conflicts with the new spec.project.
Common situations: Multi-project workspaces where one project sets maxWorkers and another uses the default; relying on default groupOrder 0 across projects with differing concurrency.
AI-assisted analysis of vitest-dev/vitest@1fa9837ec2 (2026-08-11).
Data as JSON: /api/errors/6442115d0ca6f600.
Report an issue: GitHub.
Appendix: source
Thrown at packages/vitest/src/node/pool.ts:423
return
}
const order = spec.project.config.sequence.groupOrder
const isolate = spec.project.config.isolate
// Files that have disabled parallelism and default groupOrder are set into their own group
if (isolate === true && order === 0 && spec.project.config.maxWorkers === 1) {
return sequential.specs.push([spec])
}
const maxWorkers = resolveMaxWorkers(spec.project)
groups[order] ||= { specs: [], maxWorkers }
// Multiple projects with different maxWorkers but same groupOrder
if (groups[order].maxWorkers !== maxWorkers) {
const last = groups[order].specs.at(-1)?.at(-1)?.project.name
throw new Error(`Projects "${last}" and "${spec.project.name}" have different 'maxWorkers' but same 'sequence.groupOrder'.\nProvide unique 'sequence.groupOrder' for them.`)
}
// Non-isolated single worker can receive all files at once.
// vm pools are excluded: their `isolate: false` comes from config
// resolution rather than the user, because their isolation is a fresh VM
// context per run request — batching files into a single run request
// would share one context across all of them.
if (isolate === false && maxWorkers === 1 && spec.pool !== 'vmThreads' && spec.pool !== 'vmForks') {
const previous = groups[order].specs[0]?.[0]
if (previous && previous.project.name === spec.project.name && isEqualEnvironments(spec, previous)) {
return groups[order].specs[0].push(spec)
}
}
groups[order].specs.push([spec])
})
View on GitHub (pinned to 1fa9837ec2)