20

I was working on Blaze and noticed that I was getting quite a few of those nasty backoff violations. I checked my code for infinite loops and whatnot, then checked the dev console.

Here's the timeline:

  1. I call /answers with my key and a pagesize of 100. The exact path I call:

    https://api.stackexchange.com/2.2/answers?page=1&pagesize=100&key=p3YZ1qDutpcBd7Bte2mcDw((&site=stackoverflow&order=desc&sort=creation&filter=!LeJQlFEfIbsDDTG1lReSJX
    
  2. I get back a 10 second backoff parameter. On the first call. (I'm not hammering it, this is the first time I opened it today)

  3. I allow the user to disregard it (because I'm too lazy to build in a backoff checker gizmo) and the API hates me.

I don't really think that calling /answers should send a backoff on the first time. Sources also say that /posts does the same thing, but can't be repro'd on /questions.

Edit: Upon further testing, it seems I can only repro this behavior when making calls against Stack Overflow.

Another edit: I can repro this on this simple API call in the console - where I'm only asking for the single most recent answer, and I get a 10s backoff on the first try. This can't be right.

  • 5
    This is best asked on StackApps.com, the site for API support and applications built with the API. – Martijn Pieters Apr 18 '14 at 16:51
  • 1
    Hey; if you stepped up too close to me too often, I'd tell you to stand back, too! ;) – Andrew Barber Apr 18 '14 at 17:16
  • How many first calls have you made, actually, and in what time-frame? – John Dvorak Apr 18 '14 at 17:42
  • Heh. @JanDvorak My first call today got a backoff. My first call yesterday got a backoff. And the day before that. Also, Tim Stone repro'd. Usually I make ~20 calls/day. These 'first calls' happened after at least 10 hours of silence. – Undo - Reinstate Monica Apr 18 '14 at 17:44
  • any chance you're on a shared IP? – John Dvorak Apr 18 '14 at 17:45
  • Very little, @JanDvorak. And Tim repro'd, so the chances of both of us being on an IP with a crazy-API-abuser-guy are... insanely low. – Undo - Reinstate Monica Apr 18 '14 at 17:45
  • 1
    Hmm... I'm sending cca 200 requests per day to /answers/.../ and I'm yet to see a backoff. Could there be less backoff for anonymous apps than for registered ones? – John Dvorak Apr 18 '14 at 17:49
  • 3
    I'm pretty sure the reason you're getting so much backoff is that you're ignoring it... it exists for a reason – Doorknob Apr 18 '14 at 20:45
  • 2
    @Doorknob Doubtful. I should hope the API doesn't have a memory that lasts ten hours saying "give this guy a backoff every time" – Undo - Reinstate Monica Apr 18 '14 at 20:46
  • 1
    Why does it hold no water? The docs say "...it must wait that many seconds." There's no "if it's the first call of the day" or "if it's a...different kind of app." – Josh Darnell Apr 26 '14 at 14:49
  • 1
    You shouldn't disregard the backoff. It's not really something you agree or disagree with. – Adam Lear Apr 28 '14 at 17:37
  • 8
    @AnnaLear While that's true (shame on Undo), it really doesn't make sense that the API considers this specific operation so much more expensive than all the others. Something must not be right there. – Tim Stone Apr 28 '14 at 17:47
  • 8
    @AnnaLear It's not really conceivable that requesting the last n records of the posts table is somehow more expensive than requesting the last n records of the posts table which are also questions. – Tim Stone Apr 28 '14 at 17:50
  • 2
    @AnnaLear Can I get another look at this? It's still happening and it's really annoying. – Undo - Reinstate Monica Oct 16 '14 at 21:51
  • 1
    Respected it on this IP, @AnnaLear, for at least a week. Returning a backoff on the first query on /answers for only one site seems really really odd to me. – Undo - Reinstate Monica Oct 16 '14 at 21:55
15

The API protects itself from heavy load to various subsystems that support it. In this case you were tripping a SQL server load throttle due to a very bad query plan due to a PostTypeId = @Answer rather than PostTypeId = 2 that snuck in there.

This has been corrected, and the new PostTypeId = {=Answer} (Dapper literal replacement) is live. You should no longer see a backoff. To get an idea of how bad this was...

Old query:

Table 'Users'. Scan count 0, logical reads 404.
Table 'Posts'. Scan count 1, logical reads 156368.
SQL Server Execution Times:
   CPU time = 8406 ms,  elapsed time = 9164 ms.

New query:

Table 'Users'. Scan count 0, logical reads 400.
Table 'Posts'. Scan count 1, logical reads 9460.
SQL Server Execution Times:
   CPU time = 15 ms,  elapsed time = 13 ms.

Your results should also now return just a tad bit faster.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .