Unable to correctly receive messages when there are two WebSocket connections in a dApp

[Lbqds]

Describe the bug
Unable to correctly receive messages when there are two WebSocket connections in a dApp

SDK Version

• Client: [JS]
• Version [2.17.2]

My dApp requires interacting with two blockchains simultaneously, so I have two WebSocket connections running concurrently. It worked fine before, but today during testing, I discovered that it cannot correctly receive messages from the wallet. I tried upgrading to the latest WalletConnect version, but the issue persists. Below is some detailed information:

1. Connect to Chain-A's wallet via WalletConnect. As shown in the screenshot below, it successfully sends a subscribe request and receives a response (let's call it connection-A):

2. Connect to Chain-B's wallet via WalletConnect. It also successfully sends a subscribe request(let's call it connection-B):

3. Send a request to the Chain-A's wallet via WalletConnect, connection-A does not receive the response from the wallet. Instead, the response is received by connection-B. The following screenshot shows the message from connection-B. As you can see, the topic id of the message it received corresponds to connection-A, which is very strange.

Could this be caused by an issue with the relay server when sending the messages?

[linear]

CR-590 Unable to correctly receive messages when there are two WebSocket connections in a dApp

[ganchoradkov]

hey @Lbqds, sorry for the late response! By having multiple connections I would assume you initialize the client multiple times? This is not recommened approach as clients share storage and this can lead to conflicts. Given that the client is multi-chain/multi-session by default, you should be able to connect to as many chains/sessions with a single client instance thus avoiding your multi-socket issue

[ganchoradkov]

to add to the explanation, your issue is caused exactly by theclients sharing storage. Both clients subscribe to the same topics and only the latest (in this case client B) receives the messages.
As last resort the clients accept customStoragePrefix init parameter that you can set and isolate the storages per client and avoid the issue but again, the recommened way is to use single client for all your sessions