Different graceful shutdown behavior for websockets?

[thomasjm]

The documentation for setGracefulShutdownTimeout explains how Warp enters a graceful shutdown mode when the server socket is closed. If a non-Nothing timeout is installed, the server will wait for the timeout for requests to finish up before shutting down the server.

This behavior makes sense for regular HTTP requests, which can be expected to finish up at some point. It doesn't work as well for websocket connections established via wai-websockets, because a websocket can stay open indefinitely. Thus, if the server has no graceful shutdown timeout it will stay in the shutdown state indefinitely. Or, if it does have a timeout, it will eventually tear down the websocket connection non-gracefully. (WebSocket peers are supposed to send a close message before closing the connection.)

I'm not sure what the best solution would be, but maybe a "server is shutting down" exception could be thrown to all existing websocket handlers, which they could catch use to close down gracefully?

[kazu-yamamoto]

Sorry for the delay.

Let's talk about the exception approach. I guess that threads for web socket are willing to accept the exception but other threads are not because waiting for timeout. How to distinguish these two types of threads?

[thomasjm]

Sorry @kazu-yamamoto, I thought I responded to this already.

I was thinking that since wai-websockets lives in this same repo, there must be some way it can communicate with Warp that it's running a WebSocket thread. Might be tricky because this communication would have to happen through the WAI abstraction.

For example (just thinking out loud here) maybe Warp could provide some callback registerForServerShutdownException which a thread can use to register for these exceptions, and that callback gets passed to the websocketsOr function and called there?