Cannot make Revision current through code change (publisher)

I have two revisions:

{
  "name": "myApi",
  "properties": {
    "apiRevision": "1",
    "apiVersion": "v1",
    "isCurrent": true,
}

{
  "name": "myApi;rev=2",
  "properties": {
    "apiRevision": "2",
    "apiVersion": "v1",
}

When I set revision 2 to be current in the portal, here is the code change the extractor tool makes in a PR:

{
  "name": "myApi;rev=1",
  "properties": {
    "apiRevision": "1",
    "apiVersion": "v1",
}

{
  "name": "myApi",
  "properties": {
    "apiRevision": "2",
    "apiVersion": "v1",
    "isCurrent": true,
}

Note how ;rev=# has been added to the non-current revision and is removed from the current revision.

I create a new revision in code like this and merge it to the main branch:

{
  "name": "myApi;rev=3",
  "properties": {
    "apiRevision": "3",
    "apiVersion": "v1",
}

After the publisher pipeline runs, revision 3 is visible as non-current in the portal.

Then I make this revision current in the code and merge to main again:

{
  "name": "myApi;rev=2",
  "properties": {
    "apiRevision": "2",
    "apiVersion": "v1",
}

{
  "name": "myApi",
  "properties": {
    "apiRevision": "3",
    "apiVersion": "v1",
    "isCurrent": true,
}

The publisher does see I made this change in the most recent commit:

But it does not make revision 3 current in the portal.

I could not find any documentation on whether this is the expected behavior. I understand in most cases we will want to turn on a revision in the portal, like hot-swapping an appservice slot, but shouldn’t the portal reflect the updates in the code?

If I make revision 3 current in the portal, then run the extractor, all the changes say The file differs only in whitespace. I would expect the portal to reflect the code and code to reflect the portal whichever way I make the updates.

Please advise. Thank you!

[colincmac]

I’m looking into this this week. Sorry for the delay @shawnmurtagh. I’m going to do a little testing, but this does seem to be a change in behavior from previous testing we’ve had.

You’re right about possible order issues. The REST API calls around API’s, which are saved as versioned-revisioned resources only, and VersionSets, which is only a group of versioned-revisioned API’s, are very temperamental. However, we’ve accounted for these issues (for now).

You may have already surmised this, but the API name prefix ;rev=<revNumber> is for testing revisions that aren’t current. You can actually hit the API with that URI (https://<apim-name>.azure-api.net/<api-slug>/<api-version>;rev=<api-revision>/<api-operation>) and you can test a revision. It looks like you correctly changed the files in code based on what you showed.

If you had a public repo I could look at with PR’s it would help! Either way, I’ll test this on my side to see if I can do an E2E reproduction of your issue.

[waelkdouh]

Closing this issue due to lack of activity.