-
Notifications
You must be signed in to change notification settings - Fork 125
Always clear read idle timeout at the end of a request #455
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
Always clear read idle timeout at the end of a request #455
Conversation
Nightly fails because of sendable requirements. |
@@ -415,7 +417,6 @@ struct IdleReadStateMachine { | |||
enum Action { | |||
case startIdleReadTimeoutTimer(TimeAmount) | |||
case resetIdleReadTimeoutTimer(TimeAmount) | |||
case clearIdleReadTimeoutTimer |
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.
I'm not sure, if we should remove this from the state machine tbh. The more I think about it the more I think we should just create another event (requestFailed) or something that removes the timer in the error case. Just calling clearTimer into the air and not syncing with state machine probably leads to out of sync errors in the future.
@@ -38,6 +38,7 @@ final class HTTP2ClientRequestHandler: ChannelDuplexHandler { | |||
if let newRequest = self.request, let idleReadTimeout = newRequest.requestOptions.idleReadTimeout { | |||
self.idleReadTimeoutStateMachine = .init(timeAmount: idleReadTimeout) | |||
} else { | |||
self.clearIdleReadTimeoutTimer() |
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.
I guess we should not trigger this here (though recommended by me earlier), but instead trigger a idle state machine event at all places where we cancel/fail the request.
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.
Nice, LGTM.
Motivation
As described in #453, we only clear the read idle timeout after we receive a http
.end
event. But if we e.g. cancel we did not clear the timeout and hit some precondition down the road. The same issues exists for HTTP/2 too.Changes
.clearIdleReadTimeoutTimer
action that we previously returned after we have received a http.end