14

As of recently, the Stack Exchange API v2.2 (and v2.3) returns revision_number in every revision item, even if it's not an actual edit, effectively invalidating the "may be absent" for comment in the official API docs.

Consider this API call (revisions page of that post):

{
  "items": [
    {
      "creation_date": 1603605600,
      "revision_number": 8,
      "comment": "<b>Tweeted</b> <a href=\"https://twitter.com/StackPolitics/status/1320243696386887680\" rel=\"nofollow noreferrer\">twitter.com/StackPolitics/status/1320243696386887680</a>"
    },
    {
      "creation_date": 1603389320,
      "revision_number": 7,
      "comment": "added 160 characters in body"
    },
    {
      "creation_date": 1603285228,
      "revision_number": 6,
      "comment": "add link to video"
    },
    {
      "creation_date": 1603250312,
      "revision_number": 5,
      "comment": "<b></b> "
    },
    {
      "creation_date": 1603250312,
      "revision_number": 4,
      "comment": "<b></b> "
    },
    {
      "creation_date": 1603224427,
      "revision_number": 3,
      "comment": "edited title"
    },
    {
      "creation_date": 1603222400,
      "revision_number": 2,
      "comment": "edited tags"
    },
    {
      "creation_date": 1603221507,
      "revision_number": 1
    }
  ],
  "has_more": false,
  "quota_max": 10000,
  "quota_remaining": 9973
}

The API says the number for the revision with the comment "added 160 characters in body" is 7, but the site says it's 5. Now:

  • some /revisions/<postId>/<revision_number> links are going to be invalid if revision_number is fetched from the API
  • it's impossible to find the number of revisions a post has through the API unless I fetch all the revision items

Here's how the response should look like:

{
  "items": [
    {
      "creation_date": 1603605600,
      "comment": "<b>Tweeted</b> <a href=\"https://twitter.com/StackPolitics/status/1320243696386887680\" rel=\"nofollow noreferrer\">twitter.com/StackPolitics/status/1320243696386887680</a>"
    },
    {
      "creation_date": 1603389320,
      "revision_number": 5,
      "comment": "added 160 characters in body"
    },
    {
      "creation_date": 1603285228,
      "revision_number": 4,
      "comment": "add link to video"
    },
    {
      "creation_date": 1603250312,
      "comment": "<b></b> "
    },
    {
      "creation_date": 1603250312,
      "comment": "<b></b> "
    },
    {
      "creation_date": 1603224427,
      "revision_number": 3,
      "comment": "edited title"
    },
    {
      "creation_date": 1603222400,
      "revision_number": 2,
      "comment": "edited tags"
    },
    {
      "creation_date": 1603221507,
      "revision_number": 1
    }
  ],
  "has_more": false,
  "quota_max": 10000,
  "quota_remaining": 9973
}

This way there are no discrepancies between API's and site's revision numbers.

This is a breaking change. Please revert it.

2
  • 6
    This is definitely a change in behavior. Both SmokeDetector and metasmoke currently rely on the old behavior. It's not clear to me if this was an intentional change or a bug. I agree, the better behavior is to have revision_number match what's displayed on the site and only be valid for actual revisions. We can change how SmokeDetector, metasmoke, and others deal with this without too much difficulty, but if it was an intentional change, it would have been nice to have an announcement that the change was being made, so we could have adapted to it at the time of the change, not months later.
    – Makyen
    Oct 10 at 19:34
  • 3
    Looks like it's the same as this bug but for the API. Oct 10 at 20:04
16

The issue here was the same bug that affected post history revisions last month (as pointed out in a comment by Sonic). This issue was fixed on prod for the Public Platform shortly after it was reported. Unfortunately, while a new API build was pushed that included this issue, we forgot to build out the API after the fix was made. So this bug has been present in the prod API for the past 3+ weeks (despite the issue having been fixed in the codebase).

The fix here took me a couple of hours of not being able to reproduce the issue anywhere other than prod, followed by realizing the actual issue, and pushing out a new API build 2 minutes later. Apologies for the inconvenience.

(Some context: we only build out the prod API when there is new code being released that affects the API. Because the API is not under active development, it is not uncommon for a number of weeks to go by in between new builds being pushed out for the API.)


oh poor API
sorry, forgot to push [build]
all up to date now

You must log in to answer this question.

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