vitest-dev/vitest · error · Error

Projects "${last}" and "${spec.project.name}" have different

Error message

Projects "${last}" and "${spec.project.name}" have different 'maxWorkers' but same 'sequence.groupOrder'.
Provide unique 'sequence.groupOrder' for them.

What it means

Thrown during spec grouping when two projects share the same sequence.groupOrder value but resolve different maxWorkers. Vitest groups files by groupOrder to run them in the same parallel batch, and a single group must have one consistent maxWorkers limit, so conflicting limits for the same group order are ambiguous and rejected rather than silently picking one.

Source

Thrown at packages/vitest/src/node/pool.ts:432

      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 d568f8ce37)

Solutions

Give each project a unique sequence.groupOrder value so they land in separate groups.
Align maxWorkers across the colliding projects so the same group order is consistent.
Remove the explicit sequence.groupOrder overrides and rely on the default sequential/parallel grouping if you do not need phased execution.

Example fix

// before: both projects share groupOrder 1
export default defineWorkspace([
  { test: { name: 'a', maxWorkers: 2, sequence: { groupOrder: 1 } } },
  { test: { name: 'b', maxWorkers: 4, sequence: { groupOrder: 1 } } },
])

// after: unique groupOrder per project
export default defineWorkspace([
  { test: { name: 'a', maxWorkers: 2, sequence: { groupOrder: 1 } } },
  { test: { name: 'b', maxWorkers: 4, sequence: { groupOrder: 2 } } },
])

Defensive patterns

Strategy: validation

Validate before calling

// Validate workspace projects: no two distinct maxWorkers share a groupOrder
function validateGroupOrders(projects) {
  const byOrder = new Map()
  for (const p of projects) {
    const order = p.test?.sequence?.groupOrder ?? 0
    const workers = p.test?.maxWorkers ?? 'default'
    const prev = byOrder.get(order)
    if (prev !== undefined && prev !== workers) {
      throw new Error(`Projects share groupOrder ${order} with different maxWorkers: ${prev} vs ${workers}`)
    }
    byOrder.set(order, workers)
  }
}
validateGroupOrders(workspaceConfig.projects)

Type guard

function hasConsistentGroupOrders(projects) {
  const seen = new Map()
  for (const p of projects) {
    const order = p.test?.sequence?.groupOrder ?? 0
    const workers = JSON.stringify(p.test?.maxWorkers ?? null)
    if (seen.has(order) && seen.get(order) !== workers) return false
    seen.set(order, workers)
  }
  return true
}

Prevention

Assign unique sequence.groupOrder values whenever projects set explicit maxWorkers.
Avoid setting groupOrder unless you need phased execution.
Document the groupOrder <-> maxWorkers constraint in your workspace config.

When it happens

Trigger: Two workspace projects with the same config.sequence.groupOrder (default 0 is fine since those go through the sequential path, but a non-zero explicit value collides) but different config.maxWorkers / vitest.maxWorkers / CPU-based defaults, encountered in groupSpecs at packages/vitest/src/node/pool.ts:429-432.

Common situations: A monorepo where one project sets maxWorkers: 4 and another leaves it default but both set sequence.groupOrder: 1 to run tests in a specific phase; explicit groupOrder on projects with different CPU budgets.

Related errors

AI-assisted analysis of vitest-dev/vitest@d568f8ce37 (2026-08-03). Data as JSON: /data/errors/cc8e7e7f4b1ca84e.json. Report an issue: GitHub.