When we process a block request from user A -> user B, we remove the follow edges between user A -> user B and user B -> user A, and then add a block edge from user A -> user B.
When we process an unblock request from user A -> user B, we remove the block edge from user A -> user B.
I imagine that the "Aleksey checked that he was following me again" was either client caching, or eventual consistency latency. There's no nightly batch job or anything doing that.
Source: I work on the social graph service at Twitter.
All third party apps (except a single Enterprise tool) do not receive Promoted Tweets. They're only requested and displayed within the Twitter "Owned and Operated" clients.
The 'bug' didn't last for over a year and a half. The product has existed for that long.
The bug was in the advertiser selection process. There was an issue with the job/dataset we use to select which advertisers to choose. It should only have been people in the follow lists.
As for "a change in sort order does not normally change the contents of the lists". Due to the size of some of the lists, we don't load the entire list when we show you the first 20 or so. Therefore, we would require an insertion process.
This was a bug. We rectified it as soon as the issue was brought to our attention.
The original version of this product launched in March 2013. Its intention was to just "bump" brands in your follow lists to the top, not to start placing Promoted Accounts randomly in the list—what the headline suggests. That was the bug.
I described how the logic works above, but we're always subject to and victims of replication or cache-expiration latency. So it could have been that.