Go json.NewDecoder().Decode() Context Deadline Issue

In Go programs, context deadlines provide a means of setting timeouts for certain operations. However, a user reported an unexpected behavior when using json.NewDecoder().Decode().

User Concerns

The user expected the json.NewDecoder().Decode() to respect the context deadline set for the program. They observed that reading from the response body using ioutil.ReadAll() triggered a context deadline exceeded error, as anticipated. However, when they switched to json.NewDecoder().Decode(), no error was reported, despite the elapsed time exceeding the deadline.

Code Example

ctx, _ := context.WithTimeout(context.Background(), time.Second*5)

req, err := http.NewRequestWithContext(ctx, http.MethodGet, url, nil)
...

time.Sleep(time.Second * 6)
fmt.Println("before reading response body, context error is:", ctx.Err())
err = json.NewDecoder(resp.Body).Decode(ipResponse)
if err != nil {
    panic(err)
}
fmt.Println("Expected panic but there was none")

Answer

The discrepancy in behavior stems from the use of buffers within the net/http package. Depending on the size and configuration of the response, the body may be partially or fully buffered before it is read. This means that when json.NewDecoder().Decode() is used, the expired context may not prevent the buffered data from being accessed.

To illustrate this, a test server was created that intentionally delayed the response body. It simulated the partial buffering behavior of the net/http package. When readDoesntFail() was executed with this test server, the expected context deadline exceeded error was indeed triggered.

Conclusion

The behavior observed in the user's code highlights the potential caveats of using json.NewDecoder().Decode() with context deadlines. It is important to be aware that if the response body is large and has been completely buffered, the context deadline may not be enforced as expected.