Fixes two issues involving RCV2 updates #69
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There were two separate issues that resulted in the re-execution of RunCommand scripts during both the upgrade from 1.3.18 to 1.3.26, and to the downgrade from 1.3.26 to 1.3.18.
For background, RC prevents reruns through a file named mrseq that contains the last sequence number executed. In a previous version, 1.3.17 - which was never placed in production - a regression was checked in where that file was deleted during the extension upgrade.
Normally during extension upgrade, these mrseq files must be migrated from one extension version to the next. However, the deletion occurred during the disable call, which executed before the upgrade. Therefore, the mrseq files were not migrated.
This issue was detected before 1.3.17 was released to production, but unfortunately the code that was actually released as 1.3.18 was the same as 1.3.17.
Besides no longer removing the mrseq files, another fix should have been added to 1.3.18 that "rehydrated" the mrseq files. Because we could not prevent legacy versions from deleting this file, the extension used the .status files - which were still extant - to replace the files.
As mentioned, the bits for 1.3.18 were the same as the faulty 1.3.17. Version 1.3.26 did contain the fixes meant for 1.3.18, but it also had code that restricted this rehydration only to versions it knew were faulty. Since it believed that 1.3.18 was correct, it did not apply the rehydration to this version.
Therefore, when the extension was upgraded from 1.3.18 to 1.3.26, the mrseq files were deleted and never rehydrated. Therefore, the extension believed the commands had never run, and re-ran them.
When downgrading from 1.3.26 to 1.3.18, the issue was different. 1.3.26 correctly did not delete the mrseq files, but the issue occurred later.
The RunCommand extension depends on Guest Agent to tell it the following in the upgrade method.
-The extension version to which we're upgrading
-The extension version from which we're upgrading
Unfortunately, a bug exists in the Linux agent that always provides the higher extension version in the "to" version. Another bug existed in that the extension was reading the wrong environment variable (there's a separate variable indicating which version the agent is calling, which for upgrades was always the higher), but ultimately the main issue is the extension was told that it was upgrading from 1.3.18 to 1.3.26, when the truth was the opposite.
As mentioned, version 1.3.26 correctly did not delete the mrseq files. However, they had already been deleted in the upgrade mentioned previously. That was because it looked for them under 1.3.18. Since these mrseq files had already been deleted, they were not migrated.
The fixes are thus the following: