API selectively ignores jsonp parameter - havok ensues

Question

UPDATE: this is happening on all routes now and seems to be getting worse. Whatever it is just started this morning.

compare url to json response

GET /1.0/users/14/badges?key=qgAq_KfDu0KYzlNG-qaTuw&jsonp=Soapi._jsonp123 HTTP/1.1

HTTP/1.1 200 OK
Server: nginx
Date: Sat, 21 Aug 2010 15:48:23 GMT
Content-Type: application/json; charset=utf-8
Connection: keep-alive
Cache-Control: private
X-AspNetMvc-Version: 2.0
X-RateLimit-Max: 10000
X-RateLimit-Current: 8018
X-AspNet-Version: 4.0.30319
Content-Length: 8302

Soapi._jsonp124({
  "badges": [
    {
      "badge_id": 1,
      "rank": "bronze",
      "name": "Teacher",
      "description": "Answered first question with score of 1 or more",
      "award_count": 1,
      "tag_based": false,
      "user": {
        "user_id": 14,
        "user_type": "registered",
        "display_name": "code poet",
        "reputation": 6667,
        "email_hash": "df4a7fbd8a054fd6193ca0ee62952f1f"
      },
      "badges_recipients_url": "/badges/1"
    },
  ]
}
)


------------------------------------------------------------------

---

Very odd.

This is currently only happening to me on the /badges route when the requests are within a few hundred milliseconds of each other but it is consistently reproducible.

I can't imagine that there is anything special about that would make /badges behave any different than other routes so I would say that I have just been (un)lucky enough to not have encountered this issue before and that it exists across the board.

Again, this is 100% reproducible.

The havok ensues when the script returned for ...jsop105 tries to run itself

1. the data is not for jsonp105, it is the same data that came in jsonp102
2. jsonp102 is already disposed - boom.

------------------------------------------------------------------
GET /1.0/badges?key=qgAq_KfDu0KYzlNG-qaTuw&jsonp=Soapi._jsonp105 HTTP/1.1
Host: api.stackapps.com
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.8) Gecko/20100722 Firefox/3.6.8 ( .NET CLR 3.5.30729; .NET4.0E)
Accept: */*
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 115
Connection: keep-alive
Referer: http://localhost:17742/AlphaQuickStart.htm
Cookie: __utma=126673999.29861147.1277202313.1281423717.1282250555.10; __utmz=126673999.1280046495.7.2.utmcsr=localhost:23616|utmccn=(referral)|utmcmd=referral|utmcct=/src/SiteOrdering.htm; __qca=P0-1382565058-1277202312540; usr=t=biUFDpTmDESl&s=IUoqpvIcoUmC


HTTP/1.1 200 OK
Server: nginx
Date: Sat, 21 Aug 2010 15:30:05 GMT
Content-Type: application/json; charset=utf-8
Connection: keep-alive
Cache-Control: private
X-AspNetMvc-Version: 2.0
X-RateLimit-Max: 10000
X-RateLimit-Current: 8327
X-AspNet-Version: 4.0.30319
Content-Length: 13301

Soapi._jsonp102({
  "badges": [
    {
      "badge_id": 66,
      "rank": "bronze",
      "name": "Altruist",
      "description": "First bounty you manually awarded on another person's question",
      "award_count": 0,
      "tag_based": false,
      "badges_recipients_url": "/badges/66"
  ]
  ......
}
)

------------------------------------------------------------------

Current Workaround

The only way I can seem to ensure valid JSONP results is to ensure that there is at least 150ms between requests.

This contradicts the published throttle guidelines but does ensure valid results.

As background: please see the Throttling and Caching exlaination for Soapi.JS2 for the log of the same batch of requests that completed, consistently, without error earlier today.

Answer 1

This should be fixed now. Changes in our caching scheme were causing the jsonp parameter to be ignored.