Sending _gtfo/_goaway doesn't seem to have the desired effect

[hce]

I'm using a long lived connection to Apple's Push Notification Service. After a timeout, I close the connection by calling _gtfo on the http2 connection. However, after a much longer period I see this in the console: UNHANDLED frame: (FrameHeader {payloadLength = 29, flags = 0, streamId = 0},GoAwayFrame 3 NoError "{\"reason\":\"Shutdown\"}")

• Apparently, the _gtfo on my side did not have the desired effect;
• How do I catch frames such as the above one?

( In case it helps, the code that I'm using the library from can be found here: https://github.com/memrange/push-notify-apn/blob/master/src/Network/PushNotify/APN.hs#L383 )

[lucasdicioccio]

Hi, thanks for the bug report.

There are two broad problems:

• (a) you cannot close the connection with simply a _gtfo
• (b) I don't have a good story yet for handling exceptional frames

(a)

• _goaway/_gtfo only send a GoAwayFrame, you can diagnose whether the code actually sent any frame by modifying the underlying layers as done in the handling of the --verbose flag in the example executable: https://github.com/lucasdicioccio/http2-client/blob/master/app/Main.hs#L166-L184 .
• _goaway/_gtfo do not close the TCP/SSL connection. So it's possible that what you experience is due to the server keeping the connection open until you get the sort of timeout you experienced. I've not had the issue because in my apps the connection was the duration of the program. I'll try to expose such primitive soon.

(b)

• The library does not provide a way to handle go-away frames (without wrapping the underlying frame client -- but I'd say this approach is brittle).
• I have #6 open for the more general problem of handling connections/stream errors in a clean way because I don't believe there's enough experience around yet. => would you prefer receiving an Exception (we need to understand which thread to throwTo) or have to register a handler?

[lucasdicioccio]

Can you have a look at #33 for (a) and tell me whether you like it?

Same for #34 for (b). I'm parted with asking another handler at Http2Client creation, using throwTo to throw in the parent thread (likely the main one for the connection), or keeping as it is.

[hce]

33 looks good.

As for (b), IMHO asking for another handler is the better choice. Because when multiple connections are created from the same thread, how do you tell which connection has terminated?

[lucasdicioccio]

Thanks. For (b) it's a good point that there's no direct mapping between threads and connections. That said, in #35 I'm eyeing towards asking the thread control to be able to use withAsync throughout and avoid most async-exceptions bugs this way. Hence, a user who wants to run multiple concurrent connections would have to start multiple threads/asyncs. I agree that #34 on itself is insufficiently safe though. If you are happy with #33 for this bug, please close this bug (and I'll cut a release). We can discuss error-handling in #6 .

[lucasdicioccio]

Thanks. Released 0.3.0.3 on Hackage.

Expect 0.4.0.0 or 0.3.0.4 soon-ish for the exception handling thinggy :-).