test: investigate flakiness of test-net-write-after-close

[refack]

• Version: master
• Platform: freeBSD
• Subsystem: test,net

985	parallel/test-net-write-after-close	
duration_ms	60.143
severity	fail
stack	timeout

https://ci.nodejs.org/job/node-test-commit-freebsd/9623/nodes=freebsd10-64/tapResults/

[MylesBorins]

I'm seeing this rear its head in v6.x now

not ok 828 parallel/test-net-write-after-close
  ---
  duration_ms: 60.80
  severity: fail
  stack: |-
    timeout
  ...

Should we add to known flakes?

[refack]

/cc @nodejs/platform-freebsd @nodejs/streams

[Trott]

Looks like it's the usual thing with FreeBSD flakes in CI, which is a race condition triggered by load.

If you shorten the hardcoded 250ms timeout, you can trigger the race faster/easier.

Source of the problem seems to be that the connection callback can fire after 250ms on a loaded machine.

PR coming shortly to fix this...

[Trott]

Proposed fix in #14361

[refack]

Looks like it's the usual thing with FreeBSD flakes in CI, which is a race condition triggered by load.

If you shorten the hardcoded 250ms timeout, you can trigger the race faster/easier.

Source of the problem seems to be that the connection callback can fire after 250ms on a loaded machine.

PR coming shortly to fix this...

Should we start a "raw numbers to common.platformTimeout" tracking issue?