Cleanup GPF while using a PackageSourceMapping when a failed Restore brought in the package

[donnie-msft]

NuGet Product(s) Affected

Visual Studio Package Management UI

Current Behavior

When installing a package with the PM UI, if a package is brought into the GPF for the first time, but restore ultimately fails, the downloaded package remains in the GPF.

Desired Behavior

Cleanup the GPF in scenarios where restore fails.

Additional Context

No response

[zivkan]

I'm not sure this is a good idea. If the next restore needs the same package, NuGet will have to extract the package again if it's deleted after the failed restore. This is a waste of CPU & disk IO. If a future restore of the same package happens more than 30 minutes after the first time, it will have to re-download again.

If the goal is to avoid a huge GPF, I think #4980 is a better solution.

[donnie-msft]

This isn't the same problem as GPF growing indefinitely.

I created this issue after a conversation with @nkolev92 .

Here, the consideration is package source mapping. We are moving towards automatically source mapping packages during installs. The GPF's 'source' becomes a "source of truth" when analyzing whether a package can be mapped or not.

We wouldn't want an invalid state of the GPF after a failed restore, because we will be relying on that state in source mapping logic going forward.

I'll take a stab at explaining the why. Nikolche can probably articulate this better:
If a restore grabs the package from sourceA, fails for some other reason, then we now have an ambiguous sourceA in the 'nupkg.metadata' which may not want automatic source mappings to pickup and use.

[nkolev92]

If a restore grabs the package from sourceA, fails for some other reason, then we now have an ambiguous sourceA in the 'nupkg.metadata' which may not want automatic source mappings to pickup and use.

Yep, that's perfect.

In a practical example:

Say you "consider" installing package A from source X. You decide not for whatever reason.
At a later point, you install package B from source Y. B has a dependency on A. Because of the first installation, A will be seen and mapped to X. This solves the "ambiguity" problem, so it's not really a violation of the PSM promises.

However, is it what the user would've wanted? A package that they never used?

It's tricky, I'm not convinced it's a must have, but it's a tricky scenario and we should consider it.