Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Find baseline workload set in 8.0.100 folder #42435

Merged
merged 1 commit into from
Aug 12, 2024

Conversation

Forgind
Copy link
Member

@Forgind Forgind commented Jul 29, 2024

Summary
This effectively contains one commit that went into main previously but never made it into 8.0.4xx despite needing it.

This was missed for multiple reasons:

  1. The commit is already in main/9.0-previews, and the change that led to the user-visible issue was only merged in 8.0.4xx, which limits its impact.
  2. It does not reproduce until sdk and installer are put together, which means it wasn't even testable with the 8.0.4xx SDK unless it was inserted into the installer repo.
  3. It does not reproduce with MSI-based installs, as their layout is different.

Fixes #42357 and #42358

Customer Impact
The impact of the bug is that any operation involving workload garbage collection will fail. More specifically, all workload sets are always considered 'workload sets to keep,' including the baseline workload set, during garbage collection. That baseline workload set is not in the correct folder, however, which means that although we can 'discover' it when we do an initial 'find all workload sets' step, when we move to resolve it, we can't find it. This then throws an exception. This PR enables us to find it. Though a workaround, this should work for 8.0.4xx in the long term; main has both this workaround and a better long-term fix.

Regression?
This is a fix for a regression in 8.0.4xx.

Testing
I built this change, overlaid it on an SDK with the baseline workload set, verified that that workload set was discovered during garbage collection and resolved as intended, and verified that the remainder of the operation completed successfully.

Risk
The risk of this fix is low. It permits a code path that otherwise was not otherwise available.

@dotnet-issue-labeler dotnet-issue-labeler bot added Area-Workloads untriaged Request triage from a team member labels Jul 29, 2024
Copy link
Member

@nagilson nagilson left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I looked through the logic, your well-written summary of the issue (thank you), and the existing code and your change seems sound to me. It would be ideal to have sign-off from someone who is familiar with the workload set code as I am not. I think @marcpopMSFT also suggested it's too late to take this fix, unfortunately, but if we can, we should.

@marcpopMSFT marcpopMSFT added Servicing-consider and removed untriaged Request triage from a team member labels Jul 29, 2024
@marcpopMSFT
Copy link
Member

Too late for 8.0.400 but we should take for 8.0.401. Uninstall is used by <1% of customers but it's still a good amount each month worth fixing.

@rbhanda rbhanda added this to the 8.0.9 milestone Jul 30, 2024
@Forgind Forgind merged commit 4214861 into dotnet:release/8.0.4xx Aug 12, 2024
17 checks passed
@Forgind Forgind deleted the cherry-pick-changes branch August 12, 2024 17:51
@rbhanda rbhanda modified the milestones: 8.0.9, 8.0.10 Oct 7, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants