fix(client): run `connect_to` to completion even if `ResponseFuture` is canceled #3205

arnauorriols · 2023-04-18T06:28:46Z

In the previous implementation the connect_to future was spawned to let it finish when the checkout future won the race. However, in the event of the user dropping the ResponseFuture, the connect_to future was canceled as well, and all the http2 requests waiting for the connection would error as a result. This commit prevents that by spawning the connect_to future invariably (once it starts) thus covering both cases.

Fixes #3199

…is canceled In the previous implementation the `connect_to` future was spawned to let it finish when the checkout future won the race. However, in the event of the user dropping the `ResponseFuture`, the `connect_to` future was canceled as well, and all the http2 requests waiting for the connection would error as a result. This commit prevents that by spawning the `connect_to` future invariably (once it starts) thus covering both cases. Fixes hyperium#3199

…is_inherited_by_next_request

arnauorriols · 2023-04-18T06:38:57Z

I've chosen a slightly different approach than that suggested in #3199, and also taken the liberty to remove common/lazy.rs, as it is no longer used with this approach. Let me know what you think, I'm open to trying other options.

seanmonstar · 2023-04-18T20:29:33Z

taken the liberty to remove common/lazy.rs, as it is no longer used with this approach.

I think this still needs to be left in. It's there to prevent always starting a connect call, if a checkout would have been just fine. There used to be a unit test for that, but I don't think it survived the transition from futures 0.1 to async/await... (13741f5)

arnauorriols · 2023-04-19T00:21:31Z

I thought the particularity of Lazy is to implement Started, which we use to check if the connect future has already started when checkout wins. However, as in this PR we are spawning the connect future anyway, we no longer need to check if it has already started.

However if I'm not mistaken Lazy is not lazier than any other future, right? Note that the connector.connect() future is spawned only after the future returned by connect_to is polled for the first time. The following tests currently cover the requisite you mention (I know because my initial implementation didn't comply with it and these tests fail):

    dispatch_impl::alpn_h2
    dispatch_impl::client_keep_alive_0
    dispatch_impl::client_keep_alive_eager_when_chunked
    dispatch_impl::client_keep_alive_when_response_before_request_body_ends

arnauorriols · 2023-04-21T15:01:49Z

@seanmonstar could you approve the workflow again please 🙏 ?

seanmonstar · 2023-04-21T19:35:14Z

However, as in this PR we are spawning the connect future anyway

I'm thinking through this... Is this true always? I'm thinking that at least in the HTTP/1 case, after grabbing the checkout and connect_to futures and racing them, if the checkout wins immediately and the connect_to was never "started", there's no need to spawn it and trigger a new idle connection, right?

arnauorriols · 2023-04-25T09:16:28Z

However, as in this PR we are spawning the connect future anyway

I'm thinking through this... Is this true always? I'm thinking that at least in the HTTP/1 case, after grabbing the checkout and connect_to futures and racing them, if the checkout wins immediately and the connect_to was never "started", there's no need to spawn it and trigger a new idle connection, right?

I misspoke in the previous comment. What you say is exactly how it behaves (also for http2), and it is precisely the reason I claim the Lazy struct is no longer needed. What I meant is that the current implementation tries to run the connect_to future in the same task, and in the event of an error (if the connect_to future has started) spawns it in a background task to let it finish. This PR essentially removes this attempt to avoid spawning a new task for the connection attempt, and does it invariably, but instead of spawning the connect_to future, it spawns the connector.connect() future within (thus not spawning anything if the connect_to future is never polled).

arnauorriols · 2023-04-28T19:30:17Z

Let me know how do you want to resolve this. If I haven't convinced you about the Lazy I'll revert that change, no worries!

seanmonstar · 2023-04-28T19:45:09Z

Sorry, I was wrapping up a few other things, and wanted to pay this more attention to be sure I understand, because I feel this is pretty subtle. I'll take another look!

seanmonstar

OK, I see what you mean about the lazy. It's become a different form of lazy.

One downside with this is it requires spawning another task. Would it be possible to do this without a new task? Or would it require way too much juggling of the pool to get it to work?

seanmonstar · 2023-04-28T21:05:01Z

src/client/client.rs

+                return Either::Right(future::err(canceled));
+            }
+        };
+        Either::Left(Box::pin(async move {


Ok, I see, by putting the call to connector.connect() inside this sub future, async move, it won't call connect() until the first poll. Got it.

seanmonstar · 2023-04-28T21:06:33Z

tests/client.rs

+        assert!(
+            // The second response has not been canceled and it is still waiting for the connection
+            // that will never arrive
+            future::poll_fn(|ctx| Poll::Ready(Pin::new(&mut res2).poll(ctx).is_pending())).await


But will it actually fulfill with the connection? It'd be good to test that. Otherwise, a lost future here would also make this test pass.

Good point. I've implemented the suggestion. Thanks!

…n task

arnauorriols · 2023-05-02T00:06:52Z

One downside with this is it requires spawning another task. Would it be possible to do this without a new task? Or would it require way too much juggling of the pool to get it to work?

I'll give it a try!

arnauorriols added 2 commits April 18, 2023 08:26

Merge branch '0.14.x' into when_request_is_cancelled_connecting_task_…

14b9996

…is_inherited_by_next_request

Fix fmt

ea3fdb7

Fix deprecated use of conn_builder.exec.execute

241a0ff

seanmonstar reviewed Apr 28, 2023

View reviewed changes

Make second request succeed to ensure the completion of the connectio…

fa3e220

…n task

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

fix(client): run `connect_to` to completion even if `ResponseFuture` is canceled #3205

fix(client): run `connect_to` to completion even if `ResponseFuture` is canceled #3205

arnauorriols commented Apr 18, 2023 •

edited

arnauorriols commented Apr 18, 2023

seanmonstar commented Apr 18, 2023

arnauorriols commented Apr 19, 2023 •

edited

arnauorriols commented Apr 21, 2023

seanmonstar commented Apr 21, 2023

arnauorriols commented Apr 25, 2023

arnauorriols commented Apr 28, 2023

seanmonstar commented Apr 28, 2023

seanmonstar left a comment

seanmonstar Apr 28, 2023

seanmonstar Apr 28, 2023

arnauorriols May 2, 2023

arnauorriols commented May 2, 2023

fix(client): run connect_to to completion even if ResponseFuture is canceled #3205

Are you sure you want to change the base?

fix(client): run connect_to to completion even if ResponseFuture is canceled #3205

Conversation

arnauorriols commented Apr 18, 2023 • edited

arnauorriols commented Apr 18, 2023

seanmonstar commented Apr 18, 2023

arnauorriols commented Apr 19, 2023 • edited

arnauorriols commented Apr 21, 2023

seanmonstar commented Apr 21, 2023

arnauorriols commented Apr 25, 2023

arnauorriols commented Apr 28, 2023

seanmonstar commented Apr 28, 2023

seanmonstar left a comment

Choose a reason for hiding this comment

seanmonstar Apr 28, 2023

Choose a reason for hiding this comment

seanmonstar Apr 28, 2023

Choose a reason for hiding this comment

arnauorriols May 2, 2023

Choose a reason for hiding this comment

arnauorriols commented May 2, 2023

fix(client): run `connect_to` to completion even if `ResponseFuture` is canceled #3205

fix(client): run `connect_to` to completion even if `ResponseFuture` is canceled #3205

arnauorriols commented Apr 18, 2023 •

edited

arnauorriols commented Apr 19, 2023 •

edited