Skip to content

fix: client prompt return on context cancellation #1729

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 1 commit into
base: main
Choose a base branch
from
Open
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
24 changes: 8 additions & 16 deletions api/client.go
Original file line number Diff line number Diff line change
Expand Up @@ -131,34 +131,26 @@ func (c *httpClient) Do(ctx context.Context, req *http.Request) (*http.Response,
req = req.WithContext(ctx)
}
resp, err := c.client.Do(req)
defer func() {
if resp != nil {
resp.Body.Close()
}
}()

if err != nil {
return nil, nil, err
}

var body []byte
done := make(chan struct{})
done := make(chan error, 1)
go func() {
var buf bytes.Buffer
_, err = buf.ReadFrom(resp.Body)
_, err := buf.ReadFrom(resp.Body)
body = buf.Bytes()
close(done)
done <- err
}()

select {
case <-ctx.Done():
resp.Body.Close()
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This assumes that close will somehow cancel _, err := buf.ReadFrom(resp.Body). Is it true? How?

Can we have a unit tests that perhaps shows this? 🤔

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, calling resp.Body.Close() will close the underlying connection, which unblocks any pending read and returns an error.

see unit test, if okay i will add this to client_test.go

func TestDoContextCancellation(t *testing.T) {
	ts := httptest.NewServer(http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
		w.Write([]byte("partial"))
		if f, ok := w.(http.Flusher); ok {
			f.Flush()
		}

		time.Sleep(500 * time.Millisecond) // simulate delay
		w.Write([]byte(" remaining"))
	}))
	defer ts.Close()

	client, err := NewClient(Config{
		Address: ts.URL,
	})
	if err != nil {
		t.Fatalf("failed to create client: %v", err)
	}

	req, err := http.NewRequest("GET", ts.URL, nil)
	if err != nil {
		t.Fatalf("failed to create request: %v", err)
	}

	ctx, cancel := context.WithTimeout(context.Background(), 50*time.Millisecond)
	defer cancel()

	start := time.Now()
	resp, body, err := client.Do(ctx, req)
	elapsed := time.Since(start)

	if err != context.DeadlineExceeded {
		t.Errorf("expected error %v, got: %v", context.DeadlineExceeded, err)
	}
	if body != nil {
		t.Errorf("expected no body due to cancellation, got: %q", string(body))
	}
	if elapsed > 200*time.Millisecond {
		t.Errorf("Do did not return promptly on cancellation: took %v", elapsed)
	}

	if resp != nil && resp.Body != nil {
		resp.Body.Close()
	}
}

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@bwplotka could you take a look 👀

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry for lag!

Yea, looks like this behaviour is documented also in HTTP docs:

	// Body must allow Read to be called concurrently with Close.
	// In particular, calling Close should unblock a Read waiting
	// for input. <--- this one.
	Body io.ReadCloser

It would be epic to have this test yes! However instead of 500ms delay, I would block it with <-t.Context.Done() or something. This will ensure we get Do returning without Go test timeout.

Thanks!

<-done
err = resp.Body.Close()
if err == nil {
err = ctx.Err()
}
case <-done:
return resp, nil, ctx.Err()
case err = <-done:
resp.Body.Close()
return resp, body, err
}

return resp, body, err
}
Loading