x5315
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.
"If a follow or friend relationship exists it is destroyed."
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.
Only one third party app receives Promoted Tweets, and no third party apps are required to display them.
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.
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.
Introducing application-only authentication for the Twitter REST API v1.1
IFTTT Has Actually Been In Violation of Twitter’s API For Months
Also, no semicolons, yey. Coffeescript, boo.