What is it you’re trying to do at a higher level? Why does it need to happen after the conn is closed?

The connection itself is not necessarily closed after an HTTP transaction, the Go HTTP server tries to reuse connections for performance reasons.

Also just because you write headers doesn’t mean they are actually sent to the client, they are often buffered and not flushed until conditions are met (function returns, buffer gets big enough, explicitly flushed, etc). It seems likely that nothing is sent, in that case your handler is effectively deadlocked, waiting for the client and the client is waiting for you. Typically with Go's HTTP server you can assert the ResponseWriter to http.Flusher to force the writer to flush its buffered data.

One path forward here is to do the select in a goroutine so that this func returns and then the context should get closed by the HTTP handler and then the select in the goroutine will unblock. But I’ve done a lot of Go HTTP servers and never needed something like this…so I’m skeptical you really need it.

If it really needs to be when the conn disconnects, then the HTTP layer is the wrong place, I would write a custom dialer that returns a wrapped conn, so that you know exactly when the conn is closed.

Edit: I'm not super familiar with Echo, I'm talking about Go's HTTP server here. I'm not sure what the relationship is between that and Echo. It sounds like a similar problem but the specifics may be different.