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

  1. Give each project a unique test.sequence.groupOrder value.
  2. Align test.maxWorkers across projects that share a groupOrder.
  3. 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

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)