FlakyTest: ProtocolCompatibilityTest.serviceTalkToGrpcJavaTimeout #1489
Assignees
Labels
flaky tests
Unit tests are flaky
Comments
|
More detailed log from the CI captured using #1487: |
idelpivnitskiy
added a commit
to idelpivnitskiy/servicetalk
that referenced
this issue
Apr 15, 2021
Motivation: Ignore this test until apple#1489 is resolved. Otherwise, it blocks other PRs.
idelpivnitskiy
added a commit
that referenced
this issue
Apr 15, 2021
Motivation: Ignore these tests until #1489 is resolved. Otherwise, it blocks other PRs.
|
can we do the following?
|
Scottmitch
added a commit
to Scottmitch/servicetalk-1
that referenced
this issue
Sep 4, 2021
Motivation: In the event that gRPC client deadine expires it should send a RST_STREAM to the peer service. There is a scenario where this may not happen due to common transport code cleaning up internal state before propagating the error. Modifications: - gRPC utiles to propage the TimeoutException so users can see the timeout duration. - DefaultNettyConnection should still propagate channel close events in the event that a write is cancelled. - WriteStreamSubscriber should still let the close handler know that the channel outbound close event occurred even if nothing is pending to write when a ChannelOutboundListener#channelClosed event happens. This method may not always be the result of a transport error and may be a local timeout, in which case we should close the outbound side. Result: gRPC will send a RST_STREAM on client timeout. HTTP will close the channel. Fixes apple#1489.
Scottmitch
added a commit
to Scottmitch/servicetalk-1
that referenced
this issue
Sep 4, 2021
Motivation: In the event that gRPC client deadine expires it should send a RST_STREAM to the peer service. There is a scenario where this may not happen due to common transport code cleaning up internal state before propagating the error. Modifications: - gRPC utiles to propage the TimeoutException so users can see the timeout duration. - DefaultNettyConnection should still propagate channel close events in the event that a write is cancelled. - WriteStreamSubscriber should still let the close handler know that the channel outbound close event occurred even if nothing is pending to write when a ChannelOutboundListener#channelClosed event happens. This method may not always be the result of a transport error and may be a local timeout, in which case we should close the outbound side. Result: gRPC will send a RST_STREAM on client timeout. HTTP will close the channel. Fixes apple#1489.
Scottmitch
added a commit
that referenced
this issue
Sep 5, 2021
Motivation: In the event that gRPC client deadine expires it should send a RST_STREAM to the peer service. There is a scenario where this may not happen due to common transport code cleaning up internal state before propagating the error. Modifications: - gRPC utiles to propage the TimeoutException so users can see the timeout duration. - DefaultNettyConnection should still propagate channel close events in the event that a write is cancelled. - WriteStreamSubscriber should still let the close handler know that the channel outbound close event occurred even if nothing is pending to write when a ChannelOutboundListener#channelClosed event happens. This method may not always be the result of a transport error and may be a local timeout, in which case we should close the outbound side. Result: gRPC will send a RST_STREAM on client timeout. HTTP will close the channel. Fixes #1489.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
The text was updated successfully, but these errors were encountered: