pipeline handler: fix error state tracking #595
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
weissi
added
the
patch-version-bump-only
normanmaurer
requested changes
Aug 24, 2018
| func channelRead(ctx: ChannelHandlerContext, data: NIOAny) { | ||
| switch self.unwrapInboundIn(data) { | ||
| case .head: | ||
| ctx.eventLoop.execute { |
There was a problem hiding this comment.
Can you add a comment to explain why this is dispatched on the loop here?
| XCTFail("no body expected") | ||
| case .end: | ||
| ctx.eventLoop.execute { | ||
| ctx.writeAndFlush(self.wrapOutboundOut(.end(nil)), promise: nil) |
There was a problem hiding this comment.
Can you add a comment to explain why this is dispatched on the loop here?
weissi
force-pushed
the
jw-pipeline-crash
branch
2 times, most recently
from
a8014ee
to
26df093
Compare
normanmaurer
approved these changes
Aug 24, 2018
|
@swift-nio-bot test this please |
| @@ -43,6 +43,8 @@ extension HTTPServerPipelineHandlerTest { | |||
| ("testQuiescingAfterRequestAndResponseHeadsButBeforeAnyEndsThenRequestEndBeforeResponseEnd", testQuiescingAfterRequestAndResponseHeadsButBeforeAnyEndsThenRequestEndBeforeResponseEnd), | |||
| ("testQuiescingAfterRequestAndResponseHeadsButBeforeAnyEndsThenRequestEndAfterResponseEnd", testQuiescingAfterRequestAndResponseHeadsButBeforeAnyEndsThenRequestEndAfterResponseEnd), | |||
| ("testQuiescingAfterHavingReceivedOneRequestButBeforeResponseWasSentWithMoreRequestsInTheBuffer", testQuiescingAfterHavingReceivedOneRequestButBeforeResponseWasSentWithMoreRequestsInTheBuffer), | |||
| ("testParserErrorOnly", testParserErrorOnly), | |||
| ("testLegitRequestFollowedByParserErrorArrivingWhilstReponseOutstanding", testLegitRequestFollowedByParserErrorArrivingWhilstReponseOutstanding), | |||
|
Thanks @weissi for fixing this! |
Motivation: @pushkarnk hit an interesting edge case that we previously mishandled and crashed. All these conditions need to be true 1. Whilst have an ongoing request (ie. outstanding response), ... 2. ... a `HTTPParserError` arrives (which we correctly queue) 3. Later the outstanding response is completed and then ... 4. ... the `HTTPServerProtocolErrorHandler` sends a .badRequest response We previously crashed. The reason we crashed is that the `HTTPServerPipelineHandler` obviously tracks state and then asserts that no response is sent for a wrong request. It does have an affordance to allow a .badRequest response for a request it couldn't parse. However this state tracking wasn't done if the error itself was enqueued for later delivery. Thanks very much @pushkarnk for the report! Modifications: instead of delivering the error directly use the `deliverOneError` function which transitions the state correctly. Result: fewer crashes & hopefully happy Pushkar
weissi
force-pushed
the
jw-pipeline-crash
branch
from
26df093
to
8508e00
Compare
weissi
added a commit
that referenced
this pull request
Aug 29, 2018
Motivation: @pushkarnk hit an interesting edge case that we previously mishandled and crashed. All these conditions need to be true 1. Whilst have an ongoing request (ie. outstanding response), ... 2. ... a `HTTPParserError` arrives (which we correctly queue) 3. Later the outstanding response is completed and then ... 4. ... the `HTTPServerProtocolErrorHandler` sends a .badRequest response We previously crashed. The reason we crashed is that the `HTTPServerPipelineHandler` obviously tracks state and then asserts that no response is sent for a wrong request. It does have an affordance to allow a .badRequest response for a request it couldn't parse. However this state tracking wasn't done if the error itself was enqueued for later delivery. Thanks very much @pushkarnk for the report! Modifications: instead of delivering the error directly use the `deliverOneError` function which transitions the state correctly. Result: fewer crashes & hopefully happy Pushkar Motivation: Explain here the context, and why you're making that change. What is the problem you're trying to solve. Modifications: Describe the modifications you've done. Result: After your change, what will change.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Motivation:
@pushkarnk hit an interesting edge case that we previously mishandled
and crashed. All these conditions need to be true
HTTPParserErrorarrives (which we correctly queue)HTTPServerProtocolErrorHandlersends a .badRequest responseWe previously crashed. The reason we crashed is that the
HTTPServerPipelineHandlerobviously tracks state and then asserts thatno response is sent for a wrong request. It does have an affordance to
allow a .badRequest response for a request it couldn't parse. However
this state tracking wasn't done if the error itself was enqueued for
later delivery.
Thanks very much @pushkarnk for the report!
Modifications:
instead of delivering the error directly use the
deliverOneErrorfunction which transitions the state correctly.
Result:
fewer crashes & hopefully happy Pushkar