Unremovable Pairing

[simonmcl]

Describe the bug
Ran into an issue with a web based dApp that seemed to forget its pairing details. It showed up as connected on the dApp, my mobile wallet also showed up as connected. When I tried to interact with the dApp, nothing was received by the wallet. I signed out of the dApp, connected again and everything worked. Later I discovered that the mobile wallet had 2 pairings with with same dApp active and unexpired. Trying to remove both, one of them failed with an error

Serializer.symmetricKeyForTopicNotFound

And I am now unable to remove the pairing on my side. It seems like the dApp removed something but mobile never received notice and now its stuck in local cache. It has almost a month left on the expiration date so it will remain on device for a very long time

This is somewhat related to this other issue: #1344. In general, web versions of the SDKs seem to modify the local cache, and then trigger the networking (or always update the cache), whereas the Swift SDK seems to do the networking and only touch the local cache if it succeeds. Often leaving the cache in a broken state.

SDK Version

• Client: Swift
• Version: 1.18.8

To Reproduce
Steps to reproduce the behavior:
Unable to reproduce

Expected behavior
When calling disconnect, i'd expect the item to be removed no matter what happens. If dApp never receives it, user can at least recover by signing out on that side also. In the current state the user is unable to recover and is stuck with identical pairings for ~30 days

Device (please complete the following information):

• pairing topic in case its useful: f735578eb756d3b908d19eef71f675da8832dc904d67c0b1740d04bbb6b16e58

[simonmcl]

Update: this is actually now becoming very common. In at least one case I know a dApp updated multiple dependencies and lost its WC2 session somehow (I suspect this is likely a bug in wrappers around WC2 being used). And now i'm stuck with multiple copies of that connection. Others are dApps i've not used in sometime, the connection appears to be up on both sides, but its not working and I can't disconnect on mobile side

@llbartekll any chance I can request the priority of this one be moved up? Were hoping to submit our app to app store next week, and this is likely a blocker for us

[llbartekll]

Hey, I will look into it

[llbartekll]

@simonmcl could you try to upgrade your dependency to this branch and check if you can remove the now?
#1376

[simonmcl]

@llbartekll Almost. It is deleting the records now locally, but still throws the error. So my screen is telling the user that the disconnect failed, and not refreshing. Then when they back out and return to the screen its gone

[llbartekll]

hmm, it shouldn't throw anymore 🤔 can you upgrade to the last commit? do you still have stale pairing to reproduce?

[simonmcl]

@llbartekll I can't find another stale one. The last dev build that was really bad I deleted as it was causing issues with automated UI tests. Either way it worked, if the throw can't be verified i'd prefer to just catch that error in this one case on my side and suppress it for now, rather than leaving users stuck

[llbartekll]

tbh I didn't experience it myself, so it's difficult to find the cause. In the pr, in case the issue appears, the pairing will be removed anyway on your client and the func won't throw, so user won't get stuck. We are also planning to implement some simplification to pairing, so I think this should be fine for now.

please confirm if that works

[simonmcl]

@llbartekll yes thats fine for me/this ticket. Thank you for prioritising this, much appreciated

[llbartekll]

cool, i will include it in 1.19.4