The first thing is you should get the context. So if you’re getting it from a function call and you have the first parameter, it should always be the first parameter for no reason, really, other than that’s how we do it. But yeah, you should receive it and do something with it. If you are not receiving it, it doesn’t mean that there’s no context. It might be that you are missing it out, and that’s something that lots of people miss – the fact that when you have an HTTP handler, there’s a context in there. You don’t see it directly, because it’s actually hidden behind the HTTP request.
[00:24:17.20] So if you do request.context, then you get the context. And that was actually done this way because if we had added the context at the beginning of the handler as an extra parameter, then we would have broken every single interface of the HTTP package, which would have been sad.
So that’s how you do it… I would say the first thing is make sure you use it, and that you get that context, and then the next is check whether it’s canceled or not. And the good thing is that basically the way you do it is just getting a – it’s just a channel. So you do a select statement, as you were doing it from a channel; it’s like, I might either receive that context cancellation, or something else might happen. So you need to change a little bit your code, and if you’ve never done that it’s a little bit confusing, but the idea is that you should have the path that that’s the thing that you actually want to do in the path that handles the cancellation.
If you just literally do that on every single HTTP (what is the word?) handler – if in every HTTP handler you just do that, of either – like, “I’m gonna call this function, but also if this happens, just cancel it”, if the user just sends a request and cancels the request, because the TCP connection goes down, that context will be canceled. So even if the user that is hitting your REST API doesn’t know anything about contexts, you’re already getting a lot of benefit from it.