User remove subscription hell

[daniele-athome]

This is an analysis of what is happening inside Tigase and how to fix this damn issue.

Tigase doesn't handle rosters very well. It relies on the correct synchronization of several things to make it work. When a user is deleted - along with its roster - its subscribed contacts (buddies) go into an inconsistent state. This brings to several problems when it comes to the next subscription request. This is a summary of the scenarios that I've been able to reproduce.

Subscription request not sent while online

If the requested user is online (the one who got deleted before), Tigase won't send the subscription request, probably because the requestor was already subscribed to it (it might be the app's fault too for not sending the subscription request anyway, but honestly that's unfair the app did request the subscription actually). Here is a sample of the traffic from the requested user's log:

RECV (6): <presence from="[email protected]" to="[email protected]" xmlns="jabber:client" type="subscribed"/>
RECV (6): <r xmlns='urn:xmpp:sm:3' />
SENT (6): <a xmlns='urn:xmpp:sm:3' h='10'/>
RECV (6): <iq to="[email protected]/aa3bb802b8c777f6" id="rsttig5" xmlns="jabber:client" type="set"><query ver="d41d8cd98f00b204e9800998ecf8427e" xmlns="jabber:iq:roster"><item name="4bdd4f929f3a1062253e4e496bafba0bdfb5db75" subscription="none" jid="[email protected]"/></query></iq>
RECV (6): <r xmlns='urn:xmpp:sm:3' />
SENT (6): <a xmlns='urn:xmpp:sm:3' h='11'/>
SENT (6): <iq id='rsttig5' type='result'></iq>
SENT (6): <r xmlns='urn:xmpp:sm:3'/>
RECV (6): <iq to="[email protected]/aa3bb802b8c777f6" id="rsttig6" xmlns="jabber:client" type="set"><query ver="d41d8cd98f00b204e9800998ecf8427e" xmlns="jabber:iq:roster"><item name="4bdd4f929f3a1062253e4e496bafba0bdfb5db75" subscription="none" jid="[email protected]"/></query></iq>

Roster push does come in, but only the subscription preapproval finds its way to the user.
Next time the user connects, it gets the subscription request correctly, probably because Tigase watches at the roster and realizes there is a pending subscription request.

Subscription flow goes to hell

Even when the requested user accepts the subscription request, nothing happens:

SENT (7): <presence to='[email protected]' type='subscribed'></presence><presence to='[email protected]' id='5LXPg-67' type='subscribe'></presence>
Message Center starting - Intent { act=org.kontalk.action.ROSTER_LOADED cmp=org.kontalk.debug/org.kontalk.service.msgcenter.MessageCenterService }
Message Center starting - Intent { act=org.kontalk.action.PRESENCE cmp=org.kontalk.debug/org.kontalk.service.msgcenter.MessageCenterService (has extras) }
Message Center starting - Intent { act=org.kontalk.action.PRESENCE cmp=org.kontalk.debug/org.kontalk.service.msgcenter.MessageCenterService (has extras) }
SENT (7): <presence to='[email protected]' type='subscribed'></presence>
Message Center starting - Intent { act=org.kontalk.action.PRESENCE cmp=org.kontalk.debug/org.kontalk.service.msgcenter.MessageCenterService (has extras) }
SENT (7): <presence to='[email protected]' type='subscribe'></presence>

But it's not over. When the request user reconnects, it will get the request again. And once accepted, there is no presence broadcast (that is a long standing issue in Tigase by the way), so it will see the user disconnected. The situation resolves on the next connection, but it took 3 connections to make it work!!

To do

• use preapproval code from upstream master
• implement correct user removal (including roster modifications: at first connect, contacts must see appropriate roster pushes and unsubscription presences)