Skip to content
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

Mitigate zero-length writes issue. #917

Merged
merged 1 commit into from
Aug 4, 2020

Conversation

Lukasa
Copy link
Collaborator

@Lukasa Lukasa commented Aug 4, 2020

Motivation:

On some iOS releases, zero-length writes cause problems for
Network.framework. These problems can lead to difficult to debug
catastrophic failure modes, so they ought to be avoided.

NIOTransportServices provides a workaround channel handler, which we
ought to use.

Modifications:

  • Add a PlatformSupport check for whether to apply the workaround.
  • Add the workaround code to the pipeline configuration callbacks.
  • Tests

Results:

Users can work around the zero length writes problem.

@Lukasa Lukasa requested a review from glbrntt August 4, 2020 11:03
Copy link
Collaborator

@glbrntt glbrntt left a comment

Choose a reason for hiding this comment

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

Looks great, one small test suggestion.


func noZeroLengthWriteExpectation() -> XCTestExpectation {
let expectation = self.expectation(description: "Not expecting zero length write workaround")
expectation.isInverted = true
Copy link
Collaborator

Choose a reason for hiding this comment

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

Rather than inverting the expectation, can we fulfil our expectation when we see the error from not finding the handler instead?

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

We can do, but it breaks the test symmetry: I have to write two test flows instead. Is that your preference?

Copy link
Collaborator

Choose a reason for hiding this comment

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

Why two test flows? Couldn't we just pass two (Result<NIOFilterEmptyWritesHandler, Error>) -> Void closures through to _runTest and debugPipelineExpectation and run them run in an always block rather than passing through the expectation?

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Oh, yeah, we can do that. It's a bit less clean at the test site, but works fine.

Sources/GRPC/PlatformSupport.swift Show resolved Hide resolved
@glbrntt glbrntt added the 🔨 semver/patch No public API change. label Aug 4, 2020
Motivation:

On some iOS releases, zero-length writes cause problems for
Network.framework. These problems can lead to difficult to debug
catastrophic failure modes, so they ought to be avoided.

NIOTransportServices provides a workaround channel handler, which we
ought to use.

Modifications:

- Add a PlatformSupport check for whether to apply the workaround.
- Add the workaround code to the pipeline configuration callbacks.
- Tests

Results:

Users can work around the zero length writes problem.
@Lukasa Lukasa force-pushed the cb-zero-length-writes branch from 4fe97e8 to cbc422e Compare August 4, 2020 13:13
@Lukasa Lukasa requested a review from glbrntt August 4, 2020 13:13
Copy link
Collaborator

@glbrntt glbrntt left a comment

Choose a reason for hiding this comment

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

Looks great, thanks!

@glbrntt glbrntt merged commit 2b42fd9 into grpc:master Aug 4, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
🔨 semver/patch No public API change.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Only one ServerStreamingCall can response when Clientconnection built on NIOTSEventLoopGroup
2 participants