You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Quality: Global mutable call id can grow unbounded across long-lived processes (#2691) (tuanaiseo)
17
+
> - refactor: global mutable call id can grow unbounded across l
18
+
>
19
+
> `callId` is module-scoped and incremented on every invocation. In long-running test runners or embedded usage, this can grow indefinitely and eventually lose integer precision semantics for strict ordering comparisons.
> The ESM port of `createApi` (#2683, shipped in 21.1.0) replaced `createSandbox: createSandbox` with a wrapper that pushes every newly-created sandbox into the root sandbox's fake collection:
52
+
>
53
+
> createSandbox: function createSandbox(config) {
54
+
> const s = createConfiguredSandbox(config);
55
+
> sandbox.getFakes().push(s);
56
+
> return s;
57
+
> }
58
+
>
59
+
> `Sandbox#restore` then walks that collection and calls `.restore()` on each entry. Because a sub-sandbox is itself an entry, every top-level `sinon.restore()` cascades into every sub-sandbox and undoes its stubs/timers/etc. — defeating the whole point of having an isolated sub-sandbox. The same cascade hits `resetHistory` and
60
+
> `verifyAndRestore`. This is the regression reported in #2701.
61
+
>
62
+
> Restore the pre-21.1 behaviour: hand the root API a direct reference to `createConfiguredSandbox`. Sub-sandboxes are now isolated; only `subSandbox.restore()` (or `verifyAndRestore`) clears their fakes.
63
+
>
64
+
> Also flip the four sandbox tests that were locking in the buggy cascade: they now assert the parent's restore/resetHistory leaves the child untouched, with an explicit child-side cleanup at the
Quality: Global mutable call id can grow unbounded across long-lived processes (#2691) (tuanaiseo)
23
+
> - refactor: global mutable call id can grow unbounded across l
24
+
>
25
+
> `callId` is module-scoped and incremented on every invocation. In long-running test runners or embedded usage, this can grow indefinitely and eventually lose integer precision semantics for strict ordering comparisons.
> The ESM port of `createApi` (#2683, shipped in 21.1.0) replaced `createSandbox: createSandbox` with a wrapper that pushes every newly-created sandbox into the root sandbox's fake collection:
58
+
>
59
+
> createSandbox: function createSandbox(config) {
60
+
> const s = createConfiguredSandbox(config);
61
+
> sandbox.getFakes().push(s);
62
+
> return s;
63
+
> }
64
+
>
65
+
> `Sandbox#restore` then walks that collection and calls `.restore()` on each entry. Because a sub-sandbox is itself an entry, every top-level `sinon.restore()` cascades into every sub-sandbox and undoes its stubs/timers/etc. — defeating the whole point of having an isolated sub-sandbox. The same cascade hits `resetHistory` and
66
+
> `verifyAndRestore`. This is the regression reported in #2701.
67
+
>
68
+
> Restore the pre-21.1 behaviour: hand the root API a direct reference to `createConfiguredSandbox`. Sub-sandboxes are now isolated; only `subSandbox.restore()` (or `verifyAndRestore`) clears their fakes.
69
+
>
70
+
> Also flip the four sandbox tests that were locking in the buggy cascade: they now assert the parent's restore/resetHistory leaves the child untouched, with an explicit child-side cleanup at the
0 commit comments