Hot answers tagged bug
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. ...
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.
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.
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 ...
This is a bug. The timeline path seems to have several problems. More on these below. The earlier date query returns the result you expect, but look at it in the document explorer: Notice that the entry is a comment and that it has an Owning post. Now if we look at the whole timeline (filtering out some user cruft), we see: Just two revision entries ...
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 ...
This was fixed in the latest deploy. The bug was basically selecting the wrong date to display (in this case, an associated post), and the right date for filtering and what not. Since not all badges are associated with a post, not all displayed dates were set and when they were set they were off by some (basically random) amount.
As described in the /me/inbox documentation, the route is ...effectively an alias for /inbox. It is provided for consumers who make strong assumptions about operating within the context of a single site rather than the Stack Exchange network as a whole. Since it's just more or less a convenience route for the global /inbox method, it doesn't actual ...
Only top voted, non community-wiki answers of a minimum length are eligible