1a03655 in 22.214.171.124 expanded on the HTTP error checking added by 30aec9f in
It's safe to not check length in the JSON case because a truncated JSON object
I check for both string and Buffer because some calls to this function pass in
1a03655 in 126.96.36.199 expanded on the HTTP error checking added by 30aec9f in 1.4.2. Neither of these changes were aware that discoverGalaxy invokes httpHelpers.request with json:true, resulting in a `body` that is a parsed JSON object rather than a string or Buffer. Before 188.8.131.52, this had no consequences because body.length is undefined and `undefined < 90` is false, but the change to Buffer.byteLength actually made the condition true. It's safe to not check length in the JSON case because a truncated JSON object is not legal JSON (unless the truncation just drops trailing whitespace, in white case that's OK). I check for both string and Buffer because some calls to this function pass in an encoding option. Buffer.byteLength works with both types.
To deal with individual flaky tests, we often just re-run the entire test suite, which feels like an enormous waste of shared computing resources. This change automatically re-runs individual failed tests as many as two more times, and considers the test successful if any of those attempts succeeds. cc @abernix @hwillson et al.
This method appears to be causing large spikes in memory consumption on Circle CI during the `meteor --get-ready` preparation step, which often leads to the test process being killed. Also added a call in IsopackCache#_loadLocalPackage for good measure. We're now calling requestGarbageCollection pretty frequently when we run Node with --expose-gc, but that currently only happens during Circle CI tests, so I don't think we need to implement the improvements suggested in tools/utils/gc.js, yet. Previously: 35f488e, f6df21f
In the ongoing struggle with Circle CI-specific test failures, the preparatory `meteor --get-ready` has been a consistent point of failure, before any real tests have the chance to run. Using a lighter-weight command (meteor --help) that still does most of what --get-ready did seems worth a try, though it might just defer memory-intensive work until later, so we'll have to see what happens.