revision_number is returned in every revision item, even if it's not an edit

Question

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.

Answer 1

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