When I first joined the team here at Stack Exchange, Jeff just went around on the trilogy sites and made me a moderator... And he used the "elected" route instead of the "appointed" route, for reasons that are no doubt lost to time (or maybe they're preserved in chat, I can't be bothered to search).
This problem shows up on Super User and ...
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.
Confirmed; see bottom section, below.
However, please refer to Provide a way to retrieve questions and answers that have been deleted -- which is "status-planned".
This is a feature, not a bug. And this kind of feature has been requested many times. So, shush please, don't ruin it for us. ;)
You can see this behavior (for now) with this ...
Yes, that bug is annoying, especially since specifying a todate that's before the fromdate returns a valid result set, EG:
-- rather than an error.
Having the dates be equal is theoretically possible. Having negative time is impossible (in this context).
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 for ...
Confirmed the bug on a post that accrues comments much slower than a typical Stack Overflow question does.
Currently, the OP's filter returns "comment_count": 1 on that post. There are no comments.
I believe this is a side-effect/bug/quirk with how the API appears to be counting the comments. ¿Perhaps it is counting Ids in the comment table and not ...
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 ...
I believe this was related to some other throttle/quota bugs that have been recently fixed.
Basically, some networking assumptions were incorrect and alot of apps ending up appear to be coming from the same IP.
It's mentioned under the Safety section of the filters documentation that by default all response data can be safely inserted into HTML, which is why the data is pre-escaped in this case. You can try creating an unsafe filter using the unsafe parameter to use if you wish to avoid this conversion.
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.
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.
I mean, the value's not wrong, just perhaps not useful? The QPM is taken over the entire lifetime of the site, so 10005086 / 3644369.9112 = 2.745354133577943, where 3644369.9112 is
((Date.now() / 1000) - site.launch_date) / 60
I'm not sure if there'd be a better default timespan though—it's probably better to just pull the question count for the period you'...
If you have TamperMonkey installed, this simple script should fix the problem:
// @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 ...
A fix for this has been deployed.
The error was in updating the throttle after the access token was invalidated, so now the token lives on from the perspective of the request making it until it completes. It is, however, destroyed immediately from the perspective of any other requests at the time.
This field will be hidden with the next deploy.
The number had become very unreliable, and of low interest over all (as exemplified by how long it took anyone to notice it was missing...).
I intend to do some more work around app usage statistics as part of 2.0 later this year, 1.x really did not excel in this regard.
DNS went wonky on our end, this has been fixed, those responsible have been beaten.
While there's a chance it still won't resolve for some folks, all that should shake itself out within the next 15 minutes or so.
This should be fixed now.
Really fun set of bugs there actually.
In the API we delegate most tag operations to a couple (conceptually) external services, there was a dodge bit of logic in building the request w.r.t. min/max creation dates.
However, fixing that revealed another more pervasive bug around date precision. Most of the API, and the backing ...
The comments are more or less correct; caching applies to the /events endpoint just like every other method.
This is by design for now. We have looked at differing caching policies for /events and /inbox/* routes, as the minute lag on those methods is a bit heavy handed; though we still need to protect ourselves from abusive requests.
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.
Update: Evidence now suggests that the API quota rolls over at a unique time for each app. 24 hours after that app-key, plus IP, combination made its first API call.
See this chat message.
The quota does reset every 24 hours, but the time seems to wander is custom for every app-instance. Some years ago, I seem to remember it resetting around midnight UTC,...
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.