alphabetically order apiFiles before PUT #373
Conversation
|
@waelkdouh @guythetechie moving back to draft as I am still able to trigger errors by making certain revisions current. Testing edge cases. Will re-open once I have the behavior squared away. |
|
The changes do allow all revisions to be deployed and appear in API Management successfully, but it introduces a bug - if any revision other than rev1 is current, the PUT request fails with the message: I then updated the list order so current revisions are deployed before non-current revisions. In the case where revN is current and rev 1 is not, if revN is deployed before rev1, the error disappears but we're back to the original issue, where only revN deploys successfully and rev1 is missing. I then reverted my changes back to what is currently in main and paused the execution of the publisher after each API is deployed, examining how the exported template from Azure changes. When rev2 is deployed before rev1, the following occurs regardless of which API revision is current (using
When I deploy in alphabetical order so rev2 is deployed after rev1 and pause execution the same way, the following occurs (using
Essentially, when revision N is PUT first, it creates an API resource with the API version's base name and sets the revision number to N. When revision 1 is then PUT, it updates an existing API. On the other hand, when revision 1 is PUT first, it creates an API resource with the API version's base name and sets the revision number to 1. When another revision is then PUT, the url the PUT request is sent to does not correspond to an existing API, and thus creates a new API. If that revision is current, however, an error is thrown. I am closing this PR as alphabetically ordering the APIs before their PUT requests introduces an error if revN is current. |
|
@guythetechie thoughts on this? |
|
@waelkdouh @guythetechie API Release support would potentially fix/alleviate the issue the ordering introduces as it would enable making other revisions current. |
Corresponds to bug #371. All revisions should be deployed.
Currently, the APIs are deployed in random order, so revision 2 can be deployed before revision 1, which causes rev 1 to be missed.
Alphabetically ordering the API files prior to the PUT requests ensures that the list of files fed to .ForEachParallel is set in the correct order - v3 will come after v2 and v1/original, and rev3 will come after rev2 and rev1, so on and so forth.
I deployed the SampleArtifacts with an additional Swagger Petstore API to demonstrate the initial issue:
The same APIs have all revisions deployed after the change, with correct isCurrent and isOnline properties:
@waelkdouh and @guythetechie
The
.ForEachParallelon line 387 ofApi.csin the publisher means that the APIs can still be deployed in incorrect order. While the list itself that is fed to.ForEachParallelis in now in the correct order, the parallel nature of the executions may result in order issues. In the deployment logs below, you can see that the PUT request formyversionedapi-v2occurred before the PUT formyversionedapi.Updating the
.ForEachParallelto a.ForEachensures the PUT requests are made in the correct order. I have deployed using.ForEachParallelmany times and have not been able to actually cause an error or any deployment issues, though the version order can be incorrect, so I haven't made any updates here.The logs before the change were as follows:
The logs after the change were as follows:
If I change .ForEachParallel to .ForEach: