AssertionError in spdy-transport consistently causing failures while running in Chrome 69

[bdpartridge]

• Operating System: macOS High Sierra (10.13.6)
• Node Version: 8.11.1
• Yarn Version: 1.6.0
• webpack Version: 4.17.1
• webpack-dev-server Version: 3.1.6

• This is a bug
• This is a modification request

Code

I'm not including our webpack config for now, but I can include a stripped-down version if it's really needed to reproduce the problem.

Expected Behavior

webpack-dev-server works like it did in Chrome <69, and like it continues to work in other browsers (like Firefox).

Actual Behavior

After several incremental recompiles, the process errors out due to an AssertionError in the spdy-transport library:

assert.js:42
  throw new errors.AssertionError({
  ^

AssertionError [ERR_ASSERTION]: false == true
    at PriorityNode.removeChild (/Users/bpartridge/forward/fwd/gui/node_modules/spdy-transport/lib/spdy-transport/priority.js:72:3)
    at PriorityNode.remove (/Users/bpartridge/forward/fwd/gui/node_modules/spdy-transport/lib/spdy-transport/priority.js:61:15)
    at PriorityTree.add (/Users/bpartridge/forward/fwd/gui/node_modules/spdy-transport/lib/spdy-transport/priority.js:157:23)
    at Stream._initPriority (/Users/bpartridge/forward/fwd/gui/node_modules/spdy-transport/lib/spdy-transport/stream.js:101:25)
    at new Stream (/Users/bpartridge/forward/fwd/gui/node_modules/spdy-transport/lib/spdy-transport/stream.js:75:8)
    at Connection._createStream (/Users/bpartridge/forward/fwd/gui/node_modules/spdy-transport/lib/spdy-transport/connection.js:391:16)
    at Connection._handleHeaders (/Users/bpartridge/forward/fwd/gui/node_modules/spdy-transport/lib/spdy-transport/connection.js:438:21)
    at Connection._handleFrame (/Users/bpartridge/forward/fwd/gui/node_modules/spdy-transport/lib/spdy-transport/connection.js:321:10)
    at Parser.<anonymous> (/Users/bpartridge/forward/fwd/gui/node_modules/spdy-transport/lib/spdy-transport/connection.js:158:10)
    at emitOne (events.js:116:13)

This only seems to happen in Chrome, and only started after upgrading to 69.0.3497.81 (Official Build) (64-bit).

For Bugs; How can we reproduce the behavior?

• Run webpack-dev-server.
• Open URL for server in Chrome 69.
• Trigger several incremental rebuilds. For me, it routinely took around 5-7 rebuilds before the error was triggered.
• Observe that process fails due to AssertionError noted above.

Might be related to spdy-http2/spdy-transport#47.

[alexander-akait]

@bdpartridge yep, please create minimum reproducible test repo, thanks!

[davidjoy]

For those blocked by this, @misterfresh's quick, hacky fix described in this comment over on spdy-http2/spdy-transport#47 seems to have temporarily solved it for us:

spdy-http2/spdy-transport#47 (comment)

Not something I want to leave in the code base, but it at least lets us keep using our dev servers for the moment. (Thanks to @bdpartridge for the pointer/issue)

[pladaria]

@davidjoy, simply adding spdy: {protocols: ['http/1.1']} to https options in dev-server config workarounded this issue for us

[rathpc]

I also experienced this issue with the following config:

Operating System: macOS Sierra (10.12.6)
Node Version: 8.11.2
NPM Version: 6.1.0
webpack Version: 2.7.0
webpack-dev-server Version: 2.11.2

I am using the patch fix mentioned by @misterfresh with some additional logic until an official fix is released.

[alexander-akait]

Feel free to PR 👍

[ScorpAL]

@davidjoy, simply adding spdy: {protocols: ['http/1.1']} to https options in dev-server config workarounded this issue for us

Thank you. That helps me.

devServer: {
    host: '0.0.0.0',
    port: 3000,
    https: {
        spdy: {
            protocols: ['http/1.1']
        }
    }
}

[alexvervloet]

@davidjoy, simply adding spdy: {protocols: ['http/1.1']} to https options in dev-server config workarounded this issue for us

Thank you. That helps me.

devServer: {
    host: '0.0.0.0',
    port: 3000,
    https: {
        spdy: {
            protocols: ['http/1.1']
        }
    }
}

Any way to do this from create-react-app without ejecting?

[alexander-akait]

Maybe we can use this as default property for protocols

[iisisrael]

Protocol config fix worked with the caveat that I also had to remove the --https option in our dev build script run line in our package.json, so the devServer https config wouldn't get borked back to just true.