7

Oy, that was an annoying one. Subtle, as the bug only happened when you're not logged in but would be automatically logged in when you visit stackexchange.com. The actual root cause was just over-encoding a url.


6

API V2 did this, we send down: Access-Control-Allow-Credentials: false Access-Control-Allow-Methods: GET, POST Access-Control-Allow-Origin: * With every response.


5

This was fixed in the latest deploy.


5

I don't know for sure what the original problem was, but the most recent issue was a result of implementing a new badge without rebuilding the API. Once the API was pushed to production, the bug was resolved. If it happens again (especially if there's a new badge) please let me (or really any employee) know. We can contact a developer directly. From a ...


5

Recently the user name truncation issue has been fixed in the Stack Apps site, now it is looking good. Screenshot for reference:


4

These typos were fixed in the latest build.


4

This will be fixed in the next build.


4

That is the 2.1 documentation, it's just the title (and perhaps the first sentence) that hasn't been updated. All of the routes added in 2.1 are there, so you don't have to worry that it's missing anything important.


4

Tricky. This was a consequence of the API misinterpreting a normalized field used elsewhere in the system to indicate whether or not a post has upvoted answers. Everywhere else, "is answered" is true if either of the following are met: The question has an accepted answer The question has an answer with a score > 0 The API wasn't doing the "or" check. ...


4

The flag I think you're referring to was a recommend closure flag, which results in the post going to the Close Votes queue – not the actual flag queue, which currently has no backlog. Our flag response time is pretty good at the moment, sitting at a little under two and a half hours. It had recently been even better than that recently, but I've ...


4

If you have TamperMonkey installed, this simple script should fix the problem: // ==UserScript== // @name SAHPA (Stack Apps Home Page Aligner) // @namespace http://tampermonkey.net/ // @version 0.1 // @description Aligns the user names on the StackApps Home Page // @author anonymous2 // @match http://stackapps.com/ // @grant ...


3

Fun one. Changes behind the scenes to how closed reasons are handled caused the API to stop getting a real reason and start getting a null one. This was just different enough from failing to get a reason that it went unnoticed, oy. This was fixed in the most recent build.


3

This has been fixed with the latest deploy. There was a bug introduced in our move to elastic search where min/max was applied after paging results, instead of before. This meant that in any question that would typically have a lot of out-of-range results, the first page would tend to be culled down to nothing.


3

The documentation was updated sometime in the last 2 years and the API docs (version 2.2) now state that the property may be absent:


3

This should be fixed as of the latest build. Default tag wikis are a bit special behind the scenes, and the API simply wasn't looking for them at all.


3

Found it, fix has been deployed. There was a bit of confusion around loading tag data*, basically trying to get the "required", "mod only", and "sponsored" tags for api.stackexchange.com... which doesn't end well. *Data necessary for rendering revisions that have the [tag:name] markdown extensions.


3

Update: Per Kevin Montrose's answer and its comments: The bug has now been fixed and the is_answered property will return true if either of these is true: The question has an accepted answer The question has an answer with a score > 0 To detect just whether a question has an accepted answer, merely check that the accepted_answer_id property is present and ...


3

We moved from nginx to HAProxy for our SSL provider this weekend as part of a larger rollout. In the move, we shifted our header checks to the now de-facto standard SSL protocol header. While I thought I fixed all the apps relying on the old header and standardized everything internally, stackexchange.com was left out and thought your auth requests weren't ...


3

This was fixed in the latest deploy.


3

This design issue has been fixed in the How to Format section. Currently the text is visible correctly: ► backtick escapes `like _so_` Screenshot for reference:


3

The console JS was doing fuzzy matching on ?site; but that's not really correct, as you demonstrated. With the latest deploy it does an exact match if possible.


3

This seems to have been silently/magically fixed in the last 7 months (Date of Nicos Karalis' comment). Descriptions seem correct now. I had verified that they weren't correct when I upvoted this question on Apr 29 '14. Side note: It's not documented, but apparently tag-based badges are not listed unless they have been awarded at least once. Take a look ...


3

The Informed badge is removed from the "Next badge" tracking. Previously it was listed in the Available badges section. Now it is not available under the Available or Bronze section. So the bug has been fixed recently. Screenshot for reference: Copied from the MSE answer


3

These were just fixed in the latest build.


3

Yes. I would agree that the tag serves no purpose. With only 24 questions, let us lose it.


3

Based on a reasonable response for Stack Apps, this has now been done. Merged stack-exchange into support (which many of the questions already had) and deleted support from those posts where it didn't apply. These 24 questions were affected:     2332, 2371, 2372, 2373, 3045, 3136, 3408, 4457, 4617, 4699, 4888, 4942,     6155, 6189, ...


2

This was fixed in... some deploy, not entirely sure which. But it is fixed.


2

This has been fixed in the latest deploy (it also affected body turns out). We've got some changes to our search infrastructure in the pipeline, and API v2.1 is being used to test them out. You might have noticed it's had some... issues. Better to find them in an API beta than after the rollout to the Q&A sites though.


2

The little sidebar block will refer to API V2.1 starting with the next build.


Only top voted, non community-wiki answers of a minimum length are eligible