Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Overly aggressive caching for UWP #1096
I fell victim to overly aggressive caching twice today while working with UWP projects.
I was attempting to upgrade packages using the NuGet UI in VS 2015. NuGet clearly showed a new version of the package; it successfully installed into all my projects EXCEPT the UWP project. This is what it showed:
You can clearly see that the NuGet UI is offering version 110, but NuGet refuses to install it into the UWP package because its cached data says it doesn't exist.
The second time I hit this was during package restore on a CI machine. All packages restored for non-UWP projects including the same versions of other packages; however, the UWP project refused to restore the package which was there (presumably again because of cache, though the NuGet 3.1 beta command line utility was not nearly as forthcoming as the VS UI was):
I logged into the CI machine and tried to run the solution-level restore by hand, using the
Whatever package caching mechanism is in play is clearly: (a) too aggressive, (b) not in line with other NuGet restoration policies (the fact that UI finds the package and then refuses to download it and install it is mind boggling), (c) unable to be overridden by any mechanism.
This was an amazingly poor user experience.
@neurospeech this is creating extra load on the server that is already overloaded, and does not resolve the issue (because caching happens before you even go out to the wire in this case).
Please be careful with sharing it.
@bradwilson this is the caching code from DNX, we do need to improve it. You can delete the cache manually (yes I know it sucks) and we do need to improve it as soon as possible
@yishaigalatzer this is not creating extra load, in fact all it does is routes query to new version which is used in UI, package is already available on UI and on website. Problem is NuGet is breaking build, one developer adds new package and is not available to other developers. Either package should not be available on UI or if it is available, it should be available everywhere.
What happens with this proxy is that it routes from methods that hit the lucene index to methods that hit the already overburdened database. Which is a solution to when the lucene index is in bad state (and we have just deployed a major fix)/
The issue described here has to do with local caching for v3 queries that 1. Don't go through the odata server at all and hence rewrite wont help. 2. Are cached aggressively on the user machine and hence wouldn't hit the proxy.
This was referenced
Aug 26, 2015
I've fixed this for the 3.2.0 release. Installs and updates will only use cached entries newer than the start time of the package operation. If an older entry is cached from before the package was uploaded it will be cleared out.