k6 gets stuck on a broken h2c connection upgrade

[na--]

If I launch the test server from this h2c example and run the following k6 script with k6 v0.24.0 (basically, emulating what curl -v --http2 http://localhost:8080/ does, even though we don't currently support h2c connections):

import http from "k6/http";

export default function () {
   http.get("http://localhost:8080/", {
       headers: {
           "Connection": "Upgrade, HTTP2-Settings",
           "Upgrade": "h2c",
           "HTTP2-Settings": "AAMAAABkAARAAAAAAAIAAAAA",
       }
   });
}

k6 will get completely stuck... And by that I mean that neither Ctrl+C will stop it, nor will k6 exit by itself when the script duration is exceeded. It will have to be killed externally... 🤕 This currently only occurs with k6 v0.24.0, but the actual root cause of the issue lies with a change introduced in Go 1.12, which we used to compile k6 v0.24.0. So other older k6 releases compiled by it, like some master Docker images (since we build them with golang:1-alpine) or user builds could also be affected.

There are at least two things, revealed by this bug, that we need to fix. The first part is that something in the event handling inside of k6 is broken, since it shouldn't be possible to get stuck like this from a single misbehaving HTTP request, whatever else may be.

The second part is that we need to properly handle these Upgrade requests in k6. @mstoykov found the root cause of the bug (by bisecting the Go source! 🥇 ) in this Go commit: golang/go@5416204. We definitely don't want to have infinite requests, at the very least, the configured timeout values should be respected. And we also should investigate other Upgrade uses like websockets. I think this should also be unit-testable as well, so we don't relapse in the future...

[cuonglm]

The first part is that something in the event handling inside of k6 is broken, since it shouldn't be possible to get stuck like this from a single misbehaving HTTP request, whatever else may be.

Ctrl + C won't stop k6 from running.

The current behavior of k6 is catching SIGINT and SIGTERM, trigger the engine context to cancel, then it waits the engine finishing.

IIUC, we want to catch those signals and make the engine shutdown cleanly. IOW, it does mean we completely want to ignore those signals. So the behavior is expected.

You can kill the process by sending other signal than SIGINT or SIGTERM, example, SIGQUIT, by using Ctrl + \.

[na--]

This particular issue isn't about how k6 handles Ctrl+C, that's a completely separate topic we'll likely investigate in the wake of #1007 (see one of the TODOs in the PR description).

The issue here is that even when the main context is closed, regardless of how that's done (Ctrl+C, end of test, timeout, etc.), these requests are stuck and don't abort, thus causing k6 itself to also get stuck, which should never happen.