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
Fix race between activeStreams and bdp window size #5494
Changes from 8 commits
4459a50
f7515ef
ad70290
2465c21
ff5bade
30cc71c
06f7a92
067003e
9af3575
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -8041,3 +8041,43 @@ func (s) TestServerClosesConn(t *testing.T) { | |
} | ||
t.Fatalf("timed out waiting for conns to be closed by server; still open: %v", atomic.LoadInt32(&wrapLis.connsOpen)) | ||
} | ||
|
||
// TestUnexpectedEOF tests a scenario where a client invokes two unary RPC | ||
// calls. The first call receives a payload which exceeds max grpc receive | ||
// message length, and the second gets a large response. This second RPC should | ||
// not fail with unexpected.EOF. | ||
func (s) TestUnexpectedEOF(t *testing.T) { | ||
ss := &stubserver.StubServer{ | ||
UnaryCallF: func(ctx context.Context, in *testpb.SimpleRequest) (*testpb.SimpleResponse, error) { | ||
return &testpb.SimpleResponse{ | ||
Payload: &testpb.Payload{ | ||
Body: bytes.Repeat([]byte("a"), int(in.ResponseSize)), | ||
}, | ||
}, nil | ||
}, | ||
} | ||
if err := ss.Start([]grpc.ServerOption{}); err != nil { | ||
t.Fatalf("Error starting endpoint server: %v", err) | ||
} | ||
defer ss.Stop() | ||
|
||
ctx, cancel := context.WithTimeout(context.Background(), defaultTestTimeout) | ||
defer cancel() | ||
for i := 0; i < 10; i++ { | ||
// exceeds grpc.DefaultMaxRecvMessageSize, this should error with | ||
// RESOURCE_EXHAUSTED error. | ||
if _, err := ss.Client.UnaryCall(ctx, &testpb.SimpleRequest{ResponseSize: 4194304}); err != nil { | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. _, err := ss.Client.UnaryCall()
if got := status.Code(err); got != codes.ResourceExhausted {
t.Fatal
} This way you catch the case where the call doesn't fail (code will be OK), unexpectedly. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Ah good point switched. |
||
// This check doesn't fail on a non status error. However, the main | ||
// this is testing for is an unexpected EOF with a status code | ||
// INTERNAL so this is fine. | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Delete now. It does fail on a non-status error since code would be Unknown in that case. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Whoops forgot deleted. |
||
if code := status.Code(err); code != codes.ResourceExhausted { | ||
t.Fatalf("UnaryCall RPC returned error: %v, want status code %v", err, codes.ResourceExhausted) | ||
} | ||
} | ||
// Larger response that doesn't exceed DefaultMaxRecvMessageSize, this | ||
// should work normally. | ||
if _, err := ss.Client.UnaryCall(ctx, &testpb.SimpleRequest{ResponseSize: 275075}); err != nil { | ||
t.Fatalf("UnaryCall RPC failed: %v", err) | ||
} | ||
} | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please add a comment explaining that we defer because
t.mu
is heldThere was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Added "Defer as t.mu is currently held".