assert: prevent OOM when generating diff for large objects

[AbdelrahmanHafez]

Fixes #61346

Solution

Add a 2MB limit to inspectValue() output in assertion_error.js. When truncation occurs:

• A ... [truncated] marker is added to the output
• The error message indicates lines were skipped

The assertion logic is unaffected; only the error output is truncated.

Trade-offs

If both objects produce very large inspect output and happen to match exactly in the first 2MB but differ later, the diff would appear identical. However:

• The alternative is an OOM crash, which is worse
• The assertion result is still correct (=== failed)
• A truncation marker indicates output was cut off
• Users can examine error.actual and error.expected programmatically

Alternative approaches considered

1. Skip diff entirely for huge objects - Just show "Objects are not equal (output too large to diff)"
2. Smarter truncation - Find where objects differ first, truncate around that area. However, this is complex and the performance benefit is unclear: for objects with exponential paths, even traversing them could be expensive, and the subtree around the difference may still contain references to shared objects.

[AbdelrahmanHafez]

@avivkeller
Could you approve the CI run to verify if something's broken? I'd like to fix any potential issues tonight if possible.

[nodejs-github-bot]

CI: https://ci.nodejs.org/job/node-test-pull-request/70780/

[AbdelrahmanHafez]

I've investigated the CI failures:

GitHub Actions failures (coverage-linux, test-linux, test-tarball-linux, x86_64-linux): All terminated with exit code 143 due to runner shutdown signals, not test failures. The tests that completed before shutdown all passed.

##[error]The runner has received a shutdown signal.
##[error]Process completed with exit code 143.

Jenkins CI failures (node-test-commit-linuxone, node-test-commit-plinux, node-test-linux-linked-*): These show "tests failed" but I cannot access the logs to verify if they're related to this PR or infrastructure issues.

Could a maintainer please re-trigger CI or check the Jenkins logs? @avivkeller

[BridgeAR]

Suggestion: split the string into chunks of 512kb and compare each chunk and combine the output. The output will not be perfect, as the combining process would sometimes be weird, while the smaller chunks should actually be much much faster to inspect in full.

[AbdelrahmanHafez]

Good idea, will experiment with that and compare DX, and performance for any objects that are over 512kb. 👍

[AbdelrahmanHafez]

@BridgeAR
I experimented with the chunking approach. Here's what I found:

For large objects (>1MB inspect output), chunking does provide a speedup (1.3-1.5x) when there are many scattered differences. Memory usage per chunk is lower, which helps prevent OOM.

But the problem is that chunks get misaligned. We split actual and expected independently by byte size, but if the values differ in length, the boundaries shift:

ACTUAL CHUNKS                    EXPECTED CHUNKS

Chunk 0:
    prop_01: 'aaa',                  prop_01: 'aaa',
    prop_02: 'bbb',                (empty)

Chunk 1:
    prop_03: 'ccc',                  prop_02: 'MUCH_LONGER_VALUE',
    prop_04: 'ddd',                (empty)

Chunk 2:
    prop_05: 'eee',                  prop_03: 'ccc',
    prop_06: 'fff',                  prop_04: 'ddd',

When we diff Chunk 1 vs Chunk 1, we're comparing [prop_03, prop_04] against [prop_02]. The diff shows fake inserts/deletes at every boundary.

For the typical use case, both approaches are equally fast (1ms each on my machine) because Myers diff is efficient when there are few actual changes.

I'm leaning towards the 2MB truncation approach. It gives users a clear "[truncated]" message when the object is too large, and the diff output is straightforward without these artifacts.

What do you think?