I don't know all the details, but my general understanding is that
these bulk followers calls have been heavily returning 503s for quite
some time now, and this is long established, but bad, behavior. These
bulk calls are hard to support and they need to be moved over to some
form of practical pagination scheme. Ideally, we'd offer a stream of
social graph deltas on the Streaming API and this polling business
could be tightly restricted.

Bluntly, until further back-end work is in place, we can return 5k
followers reliably from the third system, or we can attempt to return
large result sets, but often throw 503s -- really, timeouts, from the
second system. We cannot return bulk operations, or use row-based
cursors, from the third system.

Scraping the social graph is certainly valuable in some cases, but
generally it's a low value proposition for users, and scraping is
often is used to support abusive behavior.

-John Kalucki
http://twitter.com/jkalucki
Services, Twitter Inc.


On Sep 7, 9:27 pm, "David W." <d...@botanicus.net> wrote:
> Hi John,
>
> On Sep 6, 3:59 pm, John Kalucki <jkalu...@gmail.com> wrote:
>
> > resources. There is minor pagination jitter in one case and a certain
> > class of row-count-based queries have to be deprecated (or limited)
> > and replaced with cursor-based queries to be practical. For now, we're
> > sending the row-count-queries queries back to the second system, which
> > is otherwise idle, but isn't consistent with the first or third
> > system.
>
> I am getting several emails per day at the moment from users telling
> me my app's results are wrong. The application currently asks for the
> entire follower/following ID list at once, using /followers/ids and /
> friends/ids. Does this count as a "row-count-query"?
>
> David

Reply via email to