Consider the following situation: * we receive presence from foo@example.com * we don't yet know what foo's capabilities hash means * the disco request is still "in-flight" From inspection of Will's fix for Bug #24250, it seems that GetContactCapabilities (and the equivalent contact attribute) will either return no capabilities at all, or the capabilities derived from an empty set of XMPP caps (e.g. Text); I'm not immediately sure which. In both cases, the contact's caps should be omitted from the returned hash table, to indicate "don't know". If we previously knew some capabilities for the contact, we should probably return those until we get the new ones, if possible?
Let "basic caps" be the capabilities we assign to every contact, i.e. currently Text. According to testing in my smcv/caps branch, the actual behaviour goes like this: 1. the transition from no presence to available presence causes a transition from unknown caps to basic caps, even before disco#info has completed 2. the transition from one caps hash to another does not cause a transition in ContactCapabilities 3. any disco#info reply causes the ContactCapabilities to be updated, even if we have more disco#info requests in-flight (this can result in caps temporarily switching off!) I think 1. and 3. are bugs, and 2. is correct.
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/telepathy/telepathy-gabble/issues/58.
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.