[v6.x] test: investigate test-fs-read-buffer-tostring-fail

[refack]

• Version: v6.x-staging
• Platform: macOS
• Subsystem: test

not ok 386 parallel/test-fs-read-buffer-tostring-fail
  ---
  duration_ms: 61.861
  severity: fail
  stack: |-
    timeout
  ...

https://ci.nodejs.org/job/node-test-commit-osx/11278/nodes=osx1010/

[refack]

Test file - https://github.com/nodejs/node/blob/v6.x-staging/test/parallel/test-fs-read-buffer-tostring-fail.js
/cc @nodejs/platform-macos @nodejs/streams @nodejs/buffer

[mcollina]

@refack I don't think it's possible to not have this test as flaky. We are generating a very big file on memory, then we try to save that extremely big file on disk, and then load it. Everything can happen in all this I/O and GC() activity.

However, one thing we can do: convert https://github.com/nodejs/node/blob/v6.x-staging/test/parallel/test-fs-read-buffer-tostring-fail.js#L29-L33 into the pattern as the end of the https://nodejs.org/api/stream.html#stream_writable_write_chunk_encoding_callback (the one using the 'drain' event). That would reduce memory allocation on the Node.js process during the setup phase.

I'm happy to review a PR that addresses this issue, and I think it would be good for someone that wants to improve their streams knowledge.

[refack]

Also in the worse case, could create a PR adding

test-fs-read-buffer-tostring-fail      : PASS,FLAKY

to https://github.com/nodejs/node/blob/v6.x-staging/test/parallel/parallel.status#L7

[Jeyanthinath]

Can I take and contribute to this ?

[bnoordhuis]

@Jeyanthinath Go for it.