Defend against parallel access to package assets cache #2159
Conversation
This can happen if certain targets are invoked in parallel on the same project having with global properties not differing sufficiently to provide each build with a unique intermediate directory. One case where this can happen is if there is a design-time build and real build happening in parallel. Another case occurs frequently in `dotnet store`. The latter may be a design flaw in `dotnet store` but the root cause hasn't been identified yet. This will at least prevent `dotnet store` from failing, but more investigation is needed to understand why `dotnet store` gets itself into this situation. Now, when we're unable to read or write the assets cache, we fall back to the same in-memory technique that is used when DisablePackageAssetsCache is set to true. We will also log a high importance message (not a warning because that can break builds with warning-as-error and this can happen outside the user's control). The intent of logging a message is to be able to get feedback if this is happening frequently. The risk the message is trying to mitigate is if we start falling back from the fast path in common cases and don't have any clues about that other than the perf hit.
|
@MattGertz for approval to take to ship room Issues fixed Description of Issue
Customer Impact Risk Testing |
| { | ||
| _reader = CreateReaderFromDisk(task, settingsHash); | ||
| } | ||
| catch (IOException) { } |
There was a problem hiding this comment.
Add a comment here about why this is swallowing errors similar to what you have in the PR description.
This can happen if certain targets are invoked in parallel on the same project
having with global properties not differing sufficiently to provide each build
with a unique intermediate directory.
One case where this can happen is if there is a design-time build and real build
happening in parallel. Another case occurs frequently in
dotnet store. Thelatter may be a design flaw in
dotnet storebut the root cause hasn't beenidentified yet. This will at least prevent
dotnet storefrom failing, but moreinvestigation is needed to understand why
dotnet storegets itself into thissituation.
Now, when we're unable to read or write the assets cache, we fall back to the
same in-memory technique that is used when DisablePackageAssetsCache is set to
true. We will also log a high importance message (not a warning because that can
break builds with warning-as-error and this can happen outside the user's
control). The intent of logging a message is to be able to get feedback if this
is happening frequently. The risk the message is trying to mitigate is if we
start falling back from the fast path in common cases and don't have any clues
about that other than the perf hit.
Fix #2149
Fix #2089
Fix dotnet/cli#9092