workload repair can recover from corrupt workload sets

[nagilson]

context

for #52090
copilot failed attempt #52338

Issue: The Workload Manifest Reader can fail with ManifestFromWorkloadSetNotFound when calling GetManifests when package managers clean up manifests from older sdk versions that were still needed by the newer version workloads.

❗ This PR is better reviewed with hiding whitespace changes.

Manual Testing Loop Demo

./artifacts/bin/redist/Debug/dotnet/dotnet exec ./artifacts/bin/redist/Debug/dotnet/sdk/10.0.103-dev/dotnet.dll --debug workload install macos
rm -rf  /workspaces/sdk2/sdk/artifacts/bin/redist/Debug/dotnet/sdk-manifests/10.0.100/microsoft.net.workload.emscripten.current/10.0.102/

./artifacts/bin/redist/Debug/dotnet/dotnet exec ./artifacts/bin/redist/Debug/dotnet/sdk/10.0.103-dev/dotnet.dll --debug workload --info

./artifacts/bin/redist/Debug/dotnet/dotnet exec ./artifacts/bin/redist/Debug/dotnet/sdk/10.0.103-dev/dotnet.dll --debug workload repair

What's this do

I considered removing the workload set entirely during workload manifest search if the manifests didn't exist and it was corrupt but this would prevent the repair from working and still require user interaction.

Removing the error is not sufficient because then we never recover from the bad state or detect the bad state.

So, now we have a separate class which tries to repair missing manifests before we start the manifest lookup. The errors for missing manifests are disabled in the recorder because the recorder will fail to initialize if the manifests are corrupted and it doesn't have the data available to repair or recover from that state. We do the sub-manifest repair because the manifests need to be in a good state for the rest of repair to have the correct data to function. The repairer being hooked into the Installer means commands such as repair will get the hook to do so, but commands such as --info never initialize an installer through the factory, so they instead print a prettier error.

Notes

I tested and confirmed:
repair, restore, update are fixed.
--info, workload --info, workload list show the small error.

[nagilson]

There's some polish needed if this isnt urgent:

1. The error string should likely contain the workload id and not just the version
2. We should try to dedupe the message if possible, despite separate assemblies
3. The MissingManifests logic is also implemented in two approaches, which has potential for consolidation
4. It may not be required to attach in the factory method and we should reconsider if we can do that at the IInstaller level
5. The sdkFeatureBand parameter is unnecessary in the CorruptionRepairer

[nagilson]

The test failure seems to be due to a change in the new, more specific error message presenting in some cases instead of an existing error message.

[marcpopMSFT]

I tested in codespaces. I can confirm that if I delete any workload manifest (after installing), I will get errors during --info, workload --info, and build. I can also confirm that repair, restore, and update all fix the problem.

The error experiences themselves could probably be cleaned up a bit as they give full exception stacks in 2/3 of those flows (workload --info is the best Ux). But this is sufficient for unblocking the customer. Need to fix the tests and review.

[nagilson]

/xlf

[github-actions]

▶️ XLF update workflow started. Track progress in this workflow run.

[nagilson]

There's some polish needed if this isnt urgent:

1. The error string should likely contain the workload id and not just the version
2. We should try to dedupe the message if possible, despite separate assemblies
3. The MissingManifests logic is also implemented in two approaches, which has potential for consolidation
4. It may not be required to attach in the factory method and we should reconsider if we can do that at the IInstaller level
5. The sdkFeatureBand parameter is unnecessary in the CorruptionRepairer

1. there is no id, just the set version. I've improved the err message
2. not easily done as it'd make a circular reference
3. fixed and realized one only searched 1 manifest root
4. not investing the time to do that
5. fixed

[nagilson]

I was still able to confirm the fix worked for me

[nagilson]

Failures now are due to dotnet-watch

[marcpopMSFT]

@nagilson can you send a belated email to tactics for approval as this still falls under servicing. 2xx was still open for changes today.

[nagilson]

Thanks, will do - We should discuss tomorrow: I believe this was for the March release, not intending for this to go into Feb since it'd need to be in servicing and only for 1.0.2xx. I'm surprised we still do servicing since this isn't in dotnet/dotnet and march will open soon, though it will impact tests results. I suppose it's because 10 at large is in servicing since it's GA'd. Anyways, will send that out.

[nagilson]

/backport to release/10.0.2xx

[github-actions]

Started backporting to release/10.0.2xx (link to workflow run)

[github-actions]

@nagilson backporting to release/10.0.2xx failed, the patch most likely resulted in conflicts. Please backport manually!

git am output

$ git am --3way --empty=keep --ignore-whitespace --keep-non-patch changes.patch

Applying: Workload Repair should detect Corrupt Workload Sets
Applying: improve workload set check
Applying: syntax errors
Applying: Consider different install roots.
Applying: workload update also tested
Applying: move the mini corrupt wkl set repair logic into installing workload command so it can be shared
Using index info to reconstruct a base tree...
M	src/Cli/dotnet/Commands/Workload/Install/WorkloadInstallCommand.cs
M	src/Cli/dotnet/Commands/Workload/InstallingWorkloadCommand.cs
M	src/Cli/dotnet/Commands/Workload/Repair/WorkloadRepairCommand.cs
M	src/Cli/dotnet/Commands/Workload/Update/WorkloadUpdateCommand.cs
M	test/dotnet.Tests/CommandTests/Workload/Update/GivenDotnetWorkloadUpdate.cs
Falling back to patching base and 3-way merge...
Auto-merging src/Cli/dotnet/Commands/Workload/Install/WorkloadInstallCommand.cs
Auto-merging src/Cli/dotnet/Commands/Workload/InstallingWorkloadCommand.cs
Auto-merging src/Cli/dotnet/Commands/Workload/Repair/WorkloadRepairCommand.cs
CONFLICT (content): Merge conflict in src/Cli/dotnet/Commands/Workload/Repair/WorkloadRepairCommand.cs
Auto-merging src/Cli/dotnet/Commands/Workload/Update/WorkloadUpdateCommand.cs
Auto-merging test/dotnet.Tests/CommandTests/Workload/Update/GivenDotnetWorkloadUpdate.cs
error: Failed to merge in the changes.
hint: Use 'git am --show-current-patch=diff' to see the failed patch
hint: When you have resolved this problem, run "git am --continue".
hint: If you prefer to skip this patch, run "git am --skip" instead.
hint: To restore the original branch and stop patching, run "git am --abort".
hint: Disable this message with "git config set advice.mergeConflict false"
Patch failed at 0006 move the mini corrupt wkl set repair logic into installing workload command so it can be shared
Error: The process '/usr/bin/git' failed with exit code 128

Link to workflow output