Bug 38603 - Incorrectly reports offline contacts as unknown if presence arrives before the roster
Summary: Incorrectly reports offline contacts as unknown if presence arrives before th...
Status: RESOLVED FIXED
Alias: None
Product: Telepathy
Classification: Unclassified
Component: gabble (show other bugs)
Version: git master
Hardware: Other All
: medium normal
Assignee: Telepathy bugs list
QA Contact: Telepathy bugs list
URL: http://cgit.collabora.com/git/user/wj...
Whiteboard: fun with pronouns
Keywords: patch
Depends on:
Blocks:
 
Reported: 2011-06-23 05:30 UTC by Will Thompson
Modified: 2011-06-24 08:00 UTC (History)
0 users

See Also:
i915 platform:
i915 features:


Attachments

Description Will Thompson 2011-06-23 05:30:45 UTC
If Gabble receives <presence type='unavailable'/> for a contact before the roster has arrived, and that contact turns out to be on the roster, their presence shows up as 'unknown' despite the fact that we know it perfectly well.

(This is an issue on Collabora's Prosody instance, where presences routinely arrive before the roster does, presumably due to looking up the shared roster?)
Comment 1 Will Thompson 2011-06-23 09:19:30 UTC
Here's a fix. I'm not really all that happy with it.

As I say in one of the commit messages, I think it would be better if GabblePresence represented peers' presences using the constructs available on XMPP (available/unavailable/error, show={...} or null) rather than GabblePresenceID, which adds a bunch of other states to muddy the waters (like invisible, which makes no sense for peers, and unknown vs. offline). I looked briefly into fixing this, but it's really invasive, not least because of the self presence (on which invisible makes sense, and on which the presence ID may be outside the range of GabblePresenceID to allow for plugin-supplied presences…).

It occurs to me that there's an edge-case which this won't cover: if we get <presence from='zie@foo.com' type='unavailable'><status>baiii</status></presence> before we receive the roster, Zie will be in the cache as unknown, and _maybe_remove() will not discard that entry because Zee had a non-NULL message. So then Zie will continue to be Unknown rather than Offline if the roster arrives and turns out to have Zie on it. I checked RFC3921, and such presences are totally legal <http://xmpp.org/rfcs/rfc3921.html#stanzas-presence-children> but I can't bring myself to care that much.
Comment 2 Will Thompson 2011-06-23 10:57:01 UTC
I've amended a couple of patches in the branch:

• “PresenceCache: discard UNKNOWN presences in maybe_remove” <http://cgit.collabora.com/git/user/wjt/telepathy-gabble-wjt.git/commit/?h=fd.o-38603-initial-contact-presence&id=d1fd28d> has had its commit message reworded—I was wrong, this is the commit that actually fixes this bug.
• “GabblePresence: start in state Unknown” <http://cgit.collabora.com/git/user/wjt/telepathy-gabble-wjt.git/commit/?h=fd.o-38603-initial-contact-presence&id=ba15096> has been amended to contain a fix to test-presence.c, and to remove misleading remarks about “slightly surprising side-effects” (since actually the previous commit fixed the bug that it would be surprising for this commit to fix).

I think the fix is *still* surprising, but less so. ;)
Comment 3 Sjoerd Simons 2011-06-24 00:22:44 UTC
R+
Comment 4 Will Thompson 2011-06-24 08:00:31 UTC
Merged; will be in 0.12.3 and 0.13.2.


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.