Have immediate context cancellations in all handlers

[grzkv]

In some handlers (e.g. render handler in zipper), the handlers do not return immediately if context was cancelled. This can lead to goroutines piling up if inflow of requests cannot be handled, among other things.

[jwkohnen]

I have climbed the call stack from app/carbonzipper.App.renderHandler() and came along pkg/backend.Renders(). It calls a bunch of pkb/backend/Backend.Render() in a goroutine and then waits in a loop for each of their result/errors. From what I can tell everything that happens inside Backend.Render() is governed by context cancellation except for a very minor edge case.

How does the delay of cancellation manifest? Is there an easy way to provoke the issue?

[gunnihinn]

How does the delay of cancellation manifest? Is there an easy way to provoke the issue?

I'm not sure what you mean by the delay of cancellation. If you're wondering how backend.Renders deals with context cancellation, you can setup backend/mock backends that cancel the context they're given.

If you're asking more about what the Render method of backend/net does when a context gets cancelled, you should also be able to setup an ad-hoc server that stalls until a context is cancelled, either with net/http/httptest or just net/http.

I wrote this back in the day, so if it's awful you can curse me. :)

[grzkv]

@jwkohnen We definitely know that context cancellations fail from time-to-time. We can clearly see the cases when the requests do not return after the request timeout is exceeded (which causes a context cancel). The exact diagnosis of this is what this issue is about.

Right now I do not know how to reproduce this. We can try to look together and figure it out.

[grzkv]

This should be resolved by the processing redesign.