Investigate flaky test-dgram-send-callback-buffer-length

[Trott]

Failed on pi1-raspbian-wheezy: https://ci.nodejs.org/job/node-test-binary-arm/1451/RUN_SUBSET=5,nodes=pi1-raspbian-wheezy/console

Refs: #5803

Looks like the usual "arbitrary timer causing flakiness" problem. Least disruptive fix at this point is probably to use common.platformTimeout().

Labelling good first contribution.

[eljefedelrodeodeljefe]

I am curious: aside from the code fix, how do you actually run the dev setup for this? Just via CI? If then how'd you go about this exactly?

[Trott]

Hmmm...yeah, unfortunately, the logical way to test one's fix would be to run a stress test on CI. Which a first-time contributor wouldn't be able to do. Removing the label...

[eljefedelrodeodeljefe]

I would give a try to gain some arm knowledge. How would you trigger CI for that exactly? Haven't worked with the jenkins stuff yet.

[Trott]

@eljefedelrodeodeljefe You can use https://ci.nodejs.org/job/node-stress-single-test/ to run a single test over and over again on a particular OS.

For most hosts, I wouldn't use a number of runs higher than 9999 because it could tie up that host (keeping it from other CI runs) for a long time (especially if the failures are frequent and they are timeouts). Depending on how many hosts we have for that OS, you could cause a bottleneck for other CI runs. Less of an issue on weekends than weekdays typically, though.

And for the Raspberry Pi devices (like this test fails on), I keep the max to 999.

[Trott]

@eljefedelrodeodeljefe Also, the go-to person for the stress test Jenkins job is @joaocgreis as he set it up and knows the most about it. But generally, you can use the #node-build or #node-dev IRC channels to ask questions if there's anything that's not clear.

[Trott]

Code is using common.platformTimeout() now and a stress test came up clean:

https://ci.nodejs.org/job/node-stress-single-test-pi1-binary/5/label=pi1-raspbian-wheezy/console

Closing

[eljefedelrodeodeljefe]

👍