deepStrictEqual rejects structurally equal array elements if a previous call contained a cycle and a previous array element is reference equal to the item in one of the arrays

Why this is a good first issue

The issue involves subtle behavior in deepStrictEqual's cycle detection and reference equality handling.

AI Summary

The issue reports incorrect behavior in assert.deepStrictEqual when dealing with cyclic references and reference equality. A test case is provided, but the fix requires understanding the comparison internals. The main blocker is the lack of documentation in the comparison utilities.

Issue Description

Version

v25.8.1

Platform

Linux codespaces-c0c7e6 6.8.0-1044-azure #50~22.04.1-Ubuntu SMP Wed Dec  3 15:13:22 UTC 2025 x86_64 GNU/Linux

Subsystem

assert

What steps will reproduce the bug?

I have included a test which reproduces the bug in a draft PR in my fork: https://github.com/CraigMacomber/node/pull/1

How often does it reproduce? Is there a required condition?

This can only happen when cycle detection has been enabled due to some prior deep equality assert containing a cycle.

It also only happens when there are some reference equal values in the expected or actual structures which are reference equal in one but not the other.

What is the expected behavior? Why is that the expected behavior?

I expect deepStrictEqual to never throw when objects have the same structure but are not reference-equal.

I expect deepStrictEqual's behaviour should not be impacted by previous calls to deepStrictEqual.

I have these expectations since they seem like intuitive assumptions to infer based on the current documentation for deepStrictEqual.

What do you see instead?

Both the above expectations are violated, see how the referenced test triggers a "Values have same structure but are not reference-equal" error from deepStrictEqual, but only if a previous call contained a cycle.

Additional information

I was going to try and include a fix and not just a reproduction of the issue, but the lack of documentation and fine-grained testing of the functions in lib/internal/util/comparisons.js made me not have the confidence to attempt a fix.

Here is a copy of the test from the linked PR so that thus bug is fully self-contained.

Note that AI was used in the construction and documentation of this bug reproduction, but I manually confirmed it reproduces on current main ( 8e8b98d3aafa018f7b30cf7878bef057acf2d235 ), v24.14.0 and v25.8.1, and that it does

GitHub Labels