websocket-next-upgrade: 3.12.3 -> 3.XX.X no auto connection upgrade?

[farnish]

Describe the bug

Hello everyone,

first of all thank you for quarkus and sorry if i simply miss a configuration or documentation point or a an important release note from 3.12.3 to 3.13.X (since 3.13.0) already does not work as expected.

I initialised my project with:

<quarkus.platform.version>**3.12.3**</quarkus.platform.version>

since i am not specifying quarkus-sub-dependencies version in my pom i assume all quarkus-extension will be resolved by my defined platform.version.

<dependency>
            <groupId>io.quarkus</groupId>
            <artifactId>quarkus-websockets-next</artifactId>
</dependency>

I want to subscribe to my brokers WebSocket-API and "consume" the incomming Tick-Data.
In order to do so, i first connect to with the demo-credentials and receive a token for the streaming API.

On receiving the token i try to connect to the streaming endpints.
On Version 3.12.3 everything is working and i receive the data.

On any Version above 3.12.3 i dont receive data and the connections get dropped after 10 seconds due to provider restrictions.

I assume but im not sure somehow the TLS "Protocol Switch" does not work like before (on Version 3.12.3).

Expected behavior

Like on Version 3.12.3 i expect to receive Tick-Data on the opened Connection:

On 3.12.3 the engine seems to automatically repond to the Upgrade Connection / Switch Protocol Server Request:

After the connection is established i am receiving Tick-Prices:

and

Actual behavior

On Version above 3.12.3 [i.e. 3.13.0 / 3.17.2] i do not receive any data or the engine seems to answer on the server "upgrade request":

Example of 3.17.2:

How to Reproduce?

Reproduce:

Clone minimal project:

1. https://gitlab.com/farnish/websocket-next-upgrade-issue/-/tree/main?ref_type=heads
2. Run with 3.17.2: quarkus dev -Djavax.net.debug=ssl:ALL
3. Change line in the pom

<quarkus.platform.version>3.17.2</quarkus.platform.version>

to
<quarkus.platform.version>3.12.3</quarkus.platform.version>

and run again quarkus dev -Djavax.net.debug=ssl:ALL

Output of uname -a or ver

Linux Meshify 5.15.133.1-microsoft-standard-WSL2 #1 SMP Thu Oct 5 21:02:42 UTC 2023 x86_64 GNU/Linux

Output of java -version

openjdk version "21.0.4" 2024-07-16 OpenJDK Runtime Environment (build 21.0.4+7-Debian-3) OpenJDK 64-Bit Server VM (build 21.0.4+7-Debian-3, mixed mode, sharing)

Quarkus version or git rev

Looking for the newly published extensions in registry.quarkus.io 3.17.2

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

Apache Maven 3.8.8 Maven home: /usr/share/maven Java version: 21.0.4, vendor: Debian, runtime: /usr/lib/jvm/java-21-openjdk-amd64 Default locale: en_US, platform encoding: UTF-8 OS name: "linux", version: "5.15.133.1-microsoft-standard-wsl2", arch: "amd64", family: "unix"

Additional information

Eventough the credentials are for a demo account please dont abuse them :)

[farnish]

I'm sorry, as expected it was a missuse of the extension from my side.
I am able to setup sub streaning-connections now by implementing a second @WebSocketClient class.

[gsmet]

/cc @mkouba
(probably a good idea to add a triage rule)

[farnish]

Follow up:

I assume the async approach changed somwhow from 3.12.3 to 3.13.X maybe with the underlaying vert.x upgrade?

I simply changed the connection to blocking as well as sending the text to subscribe to the Ticker-Stream to blocking from the referenced project and the code works as expected on 3.17.2; no second WebSocketClient class required:

                                var streamConnection = connector.get().baseUri(URI.create(baseUri))
                                        .pathParam("environment", envStreamSuffix)
                                        .connectAndAwait();
                                streamConnection.sendTextAndAwait(streamBody);

[mkouba]

Hi @farnish and thanks for the report. I think that the problem is here: https://gitlab.com/farnish/websocket-next-upgrade-issue/-/blob/main/src/main/java/test/TickConnector.java?ref_type=heads#L73. You don't subscribe to the Uni returned from connection.sendText(streamBody). And obviously, sendTextAndAwait() fixes the problem.

Indeed, there was a change/fix in 3.13 (450681e). Previously, it was not possible to subscribe lazily to the produced Uni.