v6 coverage runs can fail dues to maxHttpBufferSize change in socket.io v3

Hi guys,

Our build starts to fail when we upgrade karma to v6.0.0. All tests run without problem, but Karma thinks the browser disconnects right after executing the tests (or the browser actually disconnects, but that doesn’t make Karma yell in v5.2).

I tracked it down and reproduced with a single test running in .only (we’re using Mocha as a framework) so I suppose it’s not a problem with the actual tests, but maybe related to the actual amount of JS code we’re oading in the browser. Again, in v5.2 they run fine.

I’m attaching karma.v5.log and karma.v6.log in DEBUG level that show the exact same run, one with 5.2.3 and the other with 6.0.0. The only step in-between these two runs is the upgrade of Karma.

A few additional information on our setup (and you have the full config object at the beginning of the log file)

• The actual application is using AngularJS
• We use Mocha as our test framework
• We run tests in Chrome headless only, using karma-chrome-launcher
• We use karma-coverage-istanbul-instrumenter and karma-coverage-istanbul-reporter to generate coverage report information
• We preprocess HTML templates to make them AngularJS modules (yeah… more JS code loaded :p)

I’m kinda stuck now, not knowing where to go to track the problem even further. I will provide any additional information you may require but would appreciate help from Karma’s community. In addition, I volounteer to make a PR if we eventually find a problem in Karma itself !

Thanks, Regards,

David

[robertknight]

The maximum payload size is coming from here in engine.io: https://github.com/socketio/engine.io/blob/e5b307c16d8e7594fcec4eb23508f23f78546dc6/lib/server.js#L29.

Changing the maxHttpBufferSize value locally to a larger value solves the issue for me. Obviously this configuration needs to be overridden in the proper way.

The fact that Istanbul sends all of its code coverage data over the WebSocket in one request at the end of the test run is probably not ideal, but that’s going to be harder to fix.

[johnjbarton]

I think we can set the maxHttpBufferSize to 1e8 to avoid most cases.

From https://socket.io/docs/v3/migrating-from-2-x-to-3-0/index.html

Saner default values
  * the default value of maxHttpBufferSize was decreased from 100MB to 1MB.