test: deflake test-buffer-large-size

[jakecastelli]

The test has failed 25+ times on 7th of April and 24 times 8th of April in our CI.

This PR attempts to spread the tests into multiple file to reduce the flakiness.

[jakecastelli]

queued a stress test - https://ci.nodejs.org/job/node-stress-single-test/557/

[lpinca]

I'm not sure I understand the difference. Why using a for loop reduces the flakiness?

[jakecastelli]

Currently it is only one test that attempts to allocate 8GB of memory, the purpose of the for loop is to make them into 4 separate tests. I think it could have 2 benefits:

1. we could be able to to know which one timed out
2. potentially give more chances to gc

[jakecastelli]

Actually - now I see my stress tests start to fail on ubuntu2204-arm64 with the same timeout, I think you might be right @lpinca 🤔 it wouldn't do anything useful, do you think this also relates to the deadlock? Maybe run a major gc is a better way to deflake the test 😅 wdyt?

[lpinca]

Do you think this also relates to the deadlock?

Yes, probably.

[jakecastelli]

I've attempted to add major gc after each allocation and queued another stress test - https://ci.nodejs.org/job/node-stress-single-test/558/. This test seems having a way too high failure rate.

[RaisinTen]

Might be worth checking if distributing each of these into separate test files improves things

[nodejs-github-bot]

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

[jakecastelli]

The stress tests seem ok, the CI failures relate to other flaky tests. Are we happy to do major gc or better off separate them into different files?

[jakecastelli]

Any further actionable item should I take?

• Continue with landing this PR
• Separate the tests into multiple files

Happy to take either path 👍

[lpinca]

I would try to separate into multiple files without manually triggering GC and see what happens. Manually calling the GC is not a fix.

[jakecastelli]

what are the practical ways to verify if things've improved?

• have a few CI runs
• 1000 stress tests

Any other suggestions?

[RaisinTen]

LGTM
Added some optional suggestions to simplify the tests

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 90.22%. Comparing base (1540fc6) to head (c76d93b).
Report is 242 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main   #57789      +/-   ##
==========================================
- Coverage   90.23%   90.22%   -0.02%     
==========================================
  Files         630      630              
  Lines      185288   185518     +230     
  Branches    36344    36380      +36     
==========================================
+ Hits       167203   167387     +184     
- Misses      11006    11027      +21     
- Partials     7079     7104      +25     

see 27 files with indirect coverage changes

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[nodejs-github-bot]

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

[RaisinTen]

LGTM, thanks

[nodejs-github-bot]

Landed in 795dd8e

[aduh95]

Tests are failing on GHA with this change (https://github.com/nodejs/node/actions/runs/14865929007/job/41742567775), we'd need a manual backport PR if we want to port this change.

[jakecastelli]

I will look into the backport

[jakecastelli]

Hi @aduh95 I took a look and realised this PR was fixing the flaky test introduced in #51821 which 51821 is a semver-major PRs that contain breaking changes and should be released in the next major version. so, I think I should've added don't land on labels