RestClient: cancelling Uni subscription doesn't cancel http request, if it was in queue (all connections was busy)

[g0rba4ev]

Describe the bug

My case:

1. I subscribe on several Unis which are using RestClient async calls, but all available connections for RestClient are busy
2. Then I cancel subscriptions of this Unis
3. When connections for RestClient become available, RestClient calls executed from Uni that I just cancelled.

This is unexpected and not obvious behavior

---

I've found an Issue #41971 that was fixed, but as I see it only cancels requests that are already executing. In my case some requests (even after Uni cancelling) end up in some queue (?), and then are executed.

Prepared simple project for issue reproducing
https://github.com/g0rba4ev/quarkus_requests_not_cancelled
Check and run FooTest.java
There is a log in attachments (some lines with Responses are omitted for clarity)
log_resp_delay_10.log

I discovered that only some requests of cancelled Unis are executed, and this number of requests vary depending on delay of MockServer response.

You can change the variable delaySec at line 26 of file WiremockPlus.java and run the test to make sure of this dependency. (e.g. try 5 sec or 20 sec).

Maybe some queue of connection waiters is cleaned by some event or whatever, but I didn't manage to get any correlation between time interval from moment of cancelling Uni to moment of releasing occupied connections and number of executed requests from Uni that were cancelled.
The only correlation I've found is described above (delay of serves response)

---

I guess these "not cancelled" requests are stuck somewhere in SipmleConnectionPool, but I didn't dig deeper and I'm not sure.
Check io.vertx.core.net.impl.pool.SimpleConnectionPool.Acquire#execute method, lines under comment

// 4. Fall in waiters list

---

Feel free to ask any question.
Sincerely yours, g00d_men.

Expected behavior

All requests from cancelled Unis (requests that were in some queue) are not going to be sent

Actual behavior

Some of requests from cancelled Unis ( (requests that were in some queue) are sent

How to Reproduce?

1. Download project https://github.com/g0rba4ev/quarkus_requests_not_cancelled
2. Run FooTest.java

Or:

1. Limit the number of connections for RestClient
2. Occupy all these connections
3. Create some Unis triggering RestClient async calls (more than a number of allowed parallel connections) and subscribe on them
4. Cancel subscriptions on Unis
5. Observe (e.g. by logs) that requests are still sent despite the fact that Unis were cancelled.

Output of uname -a or ver

No response

Output of java -version

No response

Quarkus version or git rev

No response

Build tool (ie. output of mvnw --version or gradlew --version)

No response

Additional information

No response

[quarkus-bot]

/cc @cescoffier (rest-client)

[cescoffier]

There is no way to remove a request from the queue.

Could you open an issue in Vertx?

[geoand]

Thank you very much for the great reproducer @g0rba4ev!

As @cescoffier says, once we have a way to Vert.x to cancel pending requests for the HTTP Client (cc @vietj), we can leverage that here to properly cancel the pending Unis

[g0rba4ev]

@cescoffier

There is no way to remove a request from the queue.

But, as I mentioned, somehow only some of pending requests are sent, not all of them, so I guess the left requests somehow are cancelled

Could you open an issue in Vertx?

Yes, what should it be, a feature-request to allow user remove http-request from a queue?

[g0rba4ev]

Accidentally I closed the issue, could some of you @cescoffier @geoand reopen it, please
I don't have permissions to reopen

[vietj]

quarkus should keep track of cancellation, oncee a request is assigned to a queued request, quarkus should call reset on the request to signal it should not be sent.

currently there is no API to signal that a request of a request should be cancelled as this is a future.

in other words if one calls:

// Too late cannot be cancelled
Future<HttpClientRequest> fut = client.request(options);

// But what you get is a request ready to be sent
fut.onSuccess(request -> {
  // Signal the request should not be sent after all and give the request slot to the next waiter in queue
  request.reset();
});

[geoand]

Oh, I was not aware of that, thanks @vietj