Easwar Swaminathan
Easwar Swaminathan
https://github.com/grpc/grpc-go/actions/runs/10063211882/job/27817491867?pr=7432
https://github.com/grpc/grpc-go/actions/runs/10308428524/job/28535815523?pr=7458
Draining of client transport when the streamID approaches MaxStreamID was handled here: https://github.com/grpc/grpc-go/pull/5889. It contains a test for this scenario as well.
We have checks on the server for validating the incoming stream ID here: https://github.com/grpc/grpc-go/blob/master/internal/transport/http2_server.go#L369, but I can't seem to find tests for this.
> I don't think double closure is a problem that needs to be dealt with: I agree that there are things like files and conns, where Go supports multiple calls...
> When using the server in production with xds:/// + mTLS, there is guaranteed (or very often) to be a double Close() call at the shutdown stage. Hmm ... That...
@dfawley for second set of eyes.
@bozaro : Thank you very much for the stack traces. I think this is what is happening: - xDS enabled gRPC server gets a connection - This server uses a...
@dfawley : Based on our offline discussion, the changes here reflect mostly what we want. We can track the double close in the TLS code path separately (if required, and...
I can see how #6668 could be the problem maker. I understand the problem, and the fix required as well. Is there a way to easily reproduce the problem though...