Regression in Vitest 5: spying on Set.prototype.add causes a stack overflow

[fengmk2]

Describe the bug

Spying on Set.prototype.add causes infinite recursion in Vitest 5.0.1 when the method is called:

import { expect, it, vi } from 'vitest'

it('can spy on Set.prototype.add', () => {
  const spy = vi.spyOn(Set.prototype, 'add')
  try {
    new Set([1])
    expect(spy).toHaveBeenCalledWith(1)
  } finally {
    spy.mockRestore()
  }
})

Expected: the test passes and the spy records the call, as it does on Vitest 4.1.10 and 4.1.11.

Actual: the test fails with RangeError: Maximum call stack size exceeded. The stack repeatedly enters Set.add in @vitest/spy/dist/index.js.

This also reproduces with @vitest/spy alone in plain Node, without the Vitest runner or Vite. Each mock invocation in 5.0.1's spy implementation calls DIRTY_MOCK_STATES.add(...), which calls the spied method again. This bookkeeping was added in #11092.

Reproduction

Minimal reproduction repository

git clone https://github.com/why-reproductions-are-required/vitest-set-add-spy-recursion.git
cd vitest-set-add-spy-recursion
npm ci
npm test

For the smaller Node-only reproduction:

npm run repro:spy

Both commands exit with code 1 and a stack overflow on 5.0.1, which was the latest stable release when checked on 2026-09-17. Both pass on 4.1.10 and 4.1.11. The README contains the comparison commands. Vite remains pinned to 8.3.0 in all cases.

System Info

System:
  OS: macOS 26.2
  CPU: (16) arm64 Apple M4 Max
Binaries:
  Node: 24.21.0
  npm: 11.19.0
npmPackages:
  @vitest/spy: 5.0.1
  vite: 8.3.0
  vitest: 5.0.1

Used Package Manager

npm

Validations

• Follow our Code of Conduct
• Read the Contributing Guidelines.
• Read the docs.
• Check that there isn't already an issue that reports the same bug to avoid creating a duplicate.
• Check that this is a concrete bug. For Q&A open a GitHub Discussion or join our Discord Chat Server.
• The provided reproduction is a minimal reproducible example of the bug.

Codex assisted with preparing and running the reproduction and drafting this report.

[hi-ogawa]

This specifically hit Set.prototype but technically other primitive like Map/Array.prorotype are used internally of course, so likely those mocking will crash Vitest. I'm not sure how far we should guard against this in general, but fixing this specific regression of Set.prorotype.add seems reasonable to fix.

If we were to be completely free from primitive mocking effect, then it would require some primordial utility like Node does internally and stash all relevant prototype methods, which is too tedious to deal with, so it's likely out of scope:

const setAdd = Set.prototype.add.call.bind(Set.prototype.add)
const mapSet = Map.prototype.set.call.bind(Map.prototype.set)
...

[fengmk2]

Let me analyze further which other methods in the spy still need protection.

[hi-ogawa]

Ah sorry, I forgot to share what I dug in https://gist.github.com/hi-ogawa/a7ef94747e90c8a16108fa8888e63fdd#fix-direction and my impression is that it's out of scope to guard against all pre-existing global prototype mocking, but this specific Set.prototype.add should be fixed since that's rather simple and the regression is regression. I'm not sure how much we carefully guard things like these going forward though.

[fengmk2]

Three additional regressions reproduce with ordinary pass-through spies:

• Set.prototype.delete: mockClear() records a new call while removing the spy’s tracking entry, leaving its history nonempty.
• Set iterator prototype’s next: clearAllMocks() can loop indefinitely because advancing the iterator registers the spy again after clearing removes it.
• WeakRef.prototype.deref: resetAllMocks() can invoke the spy after resetting its state, leaving new calls behind. This depends on registration order.

Replacing WeakMap.prototype.get/set can also leave prototype call history uncleared. Replacing WeakRef.prototype.deref with an implementation that returns undefined makes reset tracking discard live mocks.

The recursion failures involving Array.prototype.push/shift, Function.prototype.apply, Array iteration, and Promise.prototype.then already occur in 4.1.11. The current spy implementation uses WeakMap, with no direct Map.prototype calls.

This suggests a separate follow-up for registry operations while keeping this PR focused on Set.prototype.add. Protecting Set traversal requires saving both iterator creation and next, or using a saved native forEach. The older recursion failures would require a broader compatibility change.

[fengmk2]

@hi-ogawa We should defend as much as possible. All primitive types used in spy need to be considered.