Siskin not correctly reconnecing to server when app has been in the background
thomas-daniels opened this issue ยท 10 comments
Describe the bug
I use Siskin to connect to a Prosody server with Multi-user chats. This works fine, until I put the app on the background (by switching to another app or locking my screen). When putting the app back to the foreground, it tries to reconnect, but apparently fails to do so. Instead of "Online", it shows "Joining" for all my MUCs. History between the time I put it on the background and on the foreground again isn't fetched. However, new messages to the MUC are coming through. Closing and reopening the app puts it in a working state again, but this means I always have to close the app when I don't want to look at chats anymore, even if I want to switch back shortly.
To Reproduce
Steps to reproduce the behavior:
- Open Siskin.
- Wait for it to connect to MUCs.
- Put the app on the background and wait a bit so the connection can die.
- Put the app on the foreground again.
- Reconnecting doesn't work, MUCs keep showing "Joining" instead of "Online", history of chats between steps 3 and 4 is not fetched.
Expected behavior
After step 4, Siskin should correctly reconnect to the MUCs and fetch history, as is the behavior when opening the app after it has been entirely closed.
Details (please complete the following information):
- Siskin Version: 7.3
- iOS version 15.6.1
- iPhone model 13 mini
Additional context
The server is a Prosody server with the following features:
Server Software: Prosody 0.11.4
XEP-0045: Multi-User Chat: Yes
XEP-0054: vcard-temp: Yes
XEP-0163: Personal Eventing Protocol: Yes
XEP-0163: #publish-options: Yes
XEP-0198: Stream Management: Yes (urn:xmpp:sm:3)
XEP-0280: Message Carbons: Yes (urn:xmpp:carbons:2)
XEP-0313: Message Archive Management: Yes
XEP-0363: HTTP File Upload: Yes (urn:xmpp:http:upload:0 (max. 1.0 MiB))
XEP-0398: Avatar Conversion: Yes
XEP-0411: Bookmarks Conversion: Yes
Environment:
I observed a very similar bug on an iPhone 6s with prosody 0.12.0 using cloud_notify_extensions on a nixos server.
Bug description:
After being offline (and eventually successfully receiving some push notifications), while re-opening siskin, siskin will not re-connect to my prosody server again. Instead, the account connection state icon will infinitely loop through gray (offline) and orange (connecting) states.
On server-side, I did not notice any suspicious logs (yet).
My manual workaround:
My current workaround is to go to "accounts", deactivate and then re-activate the corresponding xmpp account. This way, siskin will again immediately connect successfully.
Severity:
For tech-users, this is just a bit annoying.
However, and on my eyes, this bug is a massive showstopper for any non-tech users.
One possible dirty code workaround could be: After trying reconnect 2-3x to prosody, do a full xmpp connection shutdown and startup to bypass this re-connection procedure bug.
- Bug also occurs when
mod_cloud_notify_extensions
is disabled. So should be unrelated to it. - Bugs seems unrelated to prosody version as it occurs with prosody 0.11.4 and 0.12.0.
- Bug does not occur with other clients being connected to prosody, so should be unique to siskin.
Okay, here my findings:
- This is very likely NOT a bug in Siskin.
- Siskin just used my very own faulty DNS Server Records, thus failed to RE_Connect
- Siskin somehow did not fail when initially connecting...
Solution 1:
- By fixing port (likely 5222) and hostname (example.server) in siskin settings, it works.
Likely Solution 2:
- Correct DNS _xmpp-client _xmpp-server records at the server.
Possible improvement for Siskin:
- Better (or at least any) Error Message or Logs at repetetive re-connection fails.
@thomas-daniels Could you please reproduce my findings?
This didn't help for my case, but thanks for your comments!
I did make a new observation though - so as I explained, moving the app to the background and again to the foreground makes it fail at reconnecting. However, when moving the app in that state to the background again and moving it back to the foreground, it reconnects fine! Subsequent background-foreground actions still seem to lead to successful reconnects. It's only the first background-foreground action that appears to be a problem. I have no clue what to make of this.
With the current information, this is just guessing.
- Could you generate relevant (verbose) logs in siskin and/or server-side? Else: Could you provide your server configuration? To enable
$someone
to reproduce the bug. In case this is DNS, you will see logs from Siskin, but not from prosody (as it cannot be reached by siskin). - Which server are you trying to re-connect? Could you provide a hostname, or at least the output of the command
dig <xmppServerDomain>
? - Did you install the
mod_cloud_notify_extensions
? Did you also add its dependencylua.luaossl
? - Did you check the xmpp compliance tester?
- Did you try deleting and re-adding your account in siskin?
- Are there any warnings when runnin
prosodyctl about
orprosodyctl check
? - Do you get similar siskin behavior with an account hosted on another prosody server? (you may contact me, I can provide a temporary account on my prosody server)
Next Guess: Push notifications are broken in the server configuration, synchronization fails at re-connect.
Do push notifications work in your setup?
I've encountered an issue with stream resumption in the last few days, but it only happened with a Prosody server. I think it will be solved in the next version.
for information: a family member is complaining that they are offline, the account is enabled but not connected and she cannot retrieve the conversations. Siskin version is 7.3. Unfortunately I haven't been able to test everything that is proposed in this thread because I have access to the phone only occasionally. The account is on jabber.today.
@pirujo Your issue has nothing to do with the issue reported here (different server software). However, we do have a test build of 7.3.1 in test flight which should be already solving the issue with reconnections. Hopefully, this new version will be released soon.
hey, sorry for being silent for a while! I tried out the TestFlight build, and it appears to fix this issue indeed! Thanks for looking into it