I noticed while fixing the tp-qt4 tests to not have race conditions that the Roster manipulation API has quite error-prone semantics. For example, the PendingOperation returned by Contact::requestPresenceSubscription finishes at *some* point of time, which can be either before, or after, the time the Contact actually signals subscriptionStateChanged() to Asked or Yes, and subscriptionState() starts returning the value corresponding to the new state. The finish point depends on the actual underlying D-Bus event ordering and kernel scheduling decisions. Needless to say, this makes that PendingOperation finish event completely useless - nothing can be assumed of the Contact object's actual state at that point.

Then again, most applications probably don't need to worry about consistency between the PendingOperation and the Contact object state, since they probably just throw away the PendingOperation. However, if you feel that your application is needlessly complex due to this semantics issue, please raise the bug severity and describe your use-case so that we can design more appropriate semantics.