Using `Context` to implement timeout

Question

Assuming that I have a function that sends web requests to an API endpoint, I would like to add a timeout to the client so that if the call is taking too long, the operation breaks either by returning an error or panicing the current thread.

Another assumption is that, the client function (the function that sends web requests) comes from a library and it has been implemented in a synchronous way.

Let's have a look at the client function's signature:

func Send(params map[string]string) (*http.Response, error)

I would like to write a wrapper around this function to add a timeout mechanism. To do that, I can do:

func SendWithTimeout(ctx context.Context, params map[string]string) (*http.Response, error) {
    completed := make(chan bool)

    go func() {
        res, err := Send(params)
        _ = res
        _ = err
        completed <- true
    }()

    for {
        select {
        case <-ctx.Done():
            {
                return nil, errors.New("Cancelled")
            }
        case <-completed:
            {
                return nil, nil // just to test how this method works
            }
        }
    }
}

Now when I call the new function and pass a cancellable context, I successfully get a cancellation error, but the goroutine that is running the original Send function keeps on running to the end.

Since, the function makes an API call meaning that establishing socket/TCP connections are actually involved in the background, it is not a good practice to leave a long-running API behind the scene.

Is there any standard way to interrupt the original Send function when the context.Done() is hit?

@Inian: What exactly do you mean? It's an argument of the function — Arnold Zahrneinder, Aug 22 '22 at 07:45
If the context parameter is not passed to `Send()`, then what is the purpose of using it at all — Inian, Aug 22 '22 at 07:48
@Inian: The whole purpose is to write a wrapper around the original `Send` that supports `context` — Arnold Zahrneinder, Aug 22 '22 at 07:48

icza · Accepted Answer · 2022-08-22T07:50:26.733

3

This is a "poor" design choice to add context support to an existing API / implementation that did not support it earlier. Context support should be added to the existing Send() implementation that uses it / monitors it, renaming it to SendWithTimeout(), and provide a new Send() function that takes no context, and calls SendWithTimeout() with context.TODO() or context.Background().

For example if your Send() function makes an outgoing HTTP call, that may be achieved by using http.NewRequest() followed by Client.Do(). In the new, context-aware version use http.NewRequestWithContext().

If you have a Send() function which you cannot change, then you're "out of luck". The function itself has to support the context or cancellation. You can't abort it from the outside.

See related:

Terminating function execution if a context is cancelled

Is it possible to cancel unfinished goroutines?

Stopping running function using context timeout in Golang

cancel a blocking operation in Go

edited Aug 22 '22 at 07:50

answered Aug 22 '22 at 07:46

icza

389,944
63
907
827

Yes, what you described is correct from a design perspective. My point is how to deal with something that already exists and cannot be modified – Arnold Zahrneinder Aug 22 '22 at 07:46
1

@ArnoldZahrneinder If you can't change`Send()`, you're out of luck. You can't abort it from the outside. `Send()` itself must support context or a cancellation. – icza Aug 22 '22 at 07:48
Ok, is there any way to inject a segment of new code into an existing function? – Arnold Zahrneinder Aug 22 '22 at 07:50
@ArnoldZahrneinder There is not. – icza Aug 22 '22 at 07:50
Ok, thank you for making it clear. – Arnold Zahrneinder Aug 22 '22 at 07:53
@ArnoldZahrneinder fork the third party code. I needed this type of behavior in an `ldap` package which did not support context cancelation. The easy fix to the source was l in any blocking read functions, I monitored the context & if canceled, closed the ldap connection & that "forced" the reads to abort. – colm.anseo Aug 22 '22 at 12:47
@colm.anseo: The point of the question was to conclude if it is possible to write a wrapper that supports context around another function that cannot be modified. – Arnold Zahrneinder Aug 23 '22 at 10:25
@ArnoldZahrneinder understood - my point was the former is not possible, but the latter is not - and not as daunting as it may appear. – colm.anseo Aug 23 '22 at 11:26

Using `Context` to implement timeout

1 Answers1