Not sure why but when put() fails to write to disk, it fails with this EXISTS error:

void CacheStorageCache::PutDidCreateEntry(
    std::unique_ptr<disk_cache::Entry*> entry_ptr,
    std::unique_ptr<PutContext> put_context,
    int rv) {
  put_context->cache_entry.reset(*entry_ptr);

  if (rv != net::OK) {
    std::move(put_context->callback).Run(CACHE_STORAGE_ERROR_EXISTS);
    return;
  }

This could be corruption that we are not digging out of? There's another bug open about not digging out of cache open failures due to corruption.

@viv.phillips, if theres no sensitive/private data involved, if you could zip up your cache storage directory for the origin that fails and attach it to the bug, that could help us to figure it out.

Also, if it is due to corruption, if you move aside the cache storage directory for the failing origin, the new instance should work. Can you try that and let us know what happens?

Thnx

If you have many CacheStorage subdirectories, you can tell which directory is for which origin by looking inside the index.txt file, it's a protobuf but you can see the url of the origin in there. Each numeric directory is for a particular origin.

C:\Users\USERNAME\AppData\Local\Google\Chrome\User Data\Default\Service Worker\CacheStorage\28da9c56fde4021055a681112c092453f74d8dd8\index.txt

Looks like this behaviour depends on how the browser was launched.
I deleted the relevant cachestorage folder and used VS debugger to launch Chrome. The cache folders show up in Developer tools but no folder is created on disk and cache.put() and cache.addAll() fail.

But if I then open another instance of Chrome and nav to the localhost url then all works as expected...

Would be good to know how this problem could be avoided since it currently precludes any IDE debugging in VS

Thank you for providing more feedback. Adding requester "michaeln@chromium.org" to the cc list and removing "Needs-Feedback" label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Bit farther on:  discovered that VS uses a different Chrome user profile for remote debugging (apparently required) and think I have found the relevant files under AppData\local\microsoft\VisualStudio\version\Webtools\ChromeUserData\guid.
I see a ServiceWorker\CacheStorage folder with the relevant index.txt with two sub-folders both of which are empty except for an 'index' file.

Permissions look OK so the question is why can't Chrome write to these folders?

It's possible that index.txt or one of the index files is corrupt. If you could attach a .zip file we could know for sure.

Are you remote debugging or debugging a local instance of the browser? I'm not familiar with why ChromeUserData would be buried down there, but i'm suspicious of the setup?

Attached is a zip of the relevant CacheStorage folder.  Chrome is launched automatically when I start debugging from MS VisualStudio. The actual command used to launch is buried somewhere in the VS configuration.  This old post shows how it was done in earlier versions: https://developercommunity.visualstudio.com/content/problem/2831/vs-2017-rc1-debugging-aspnet-project-with-chrome-d.html

Their example:

"C:\Program Files (x86)\Google\Chrome\Application\chrome.exe" --no-first-run --no-default-browser-check "--user-data-dir=C:\Users\rmckee\AppData\Local\Temp\chromeVSProfile\4020adf9-2540-4236-bad8-e8f3b6e23e4e" "data:text/html;charset=utf-8,%3Chead%3E%3C/head%3E%3Cbody%3EPlease%20wait%20while%20we%20attach%3C/body%3E%3C!--4020adf9-2540-4236-bad8-e8f3b6e23e4e--%3E" --remote-debugging-port=50384"

Deleted: CacheStorage.zip 2.5 KB

CacheStorage.zip 2.5 KB Download

#8, thank you for the data to look at

Unable to triage this issue from TE-End, hence adding "TE-NeedsTriageHelp" for further triage

Sorry to ask for more info - can you do the following steps:

1. Restart chrome to get a clean state
2. Wait until problem occurs, or do the local reproduction
3. Go to about://histograms (reload a couple times to make sure it's totally populated) and attach or email me that file?

This will give us more clues about what exactly might be failing.

Adding Chris as he's doing work on CacheStorage just in case this rings any bells.

Attached as requested. 
If it helps I can send the service worker js code....

Deleted: About Histograms.html 1.1 MB

About Histograms.html 1.1 MB View Download

Thank you for providing more feedback. Adding requester "dmurph@chromium.org" to the cc list and removing "Needs-Feedback" label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Looking at falken's comment on #6, this looks like probably a bug. It also looks like we don't have histograms on commit errors? We should do an uma & reporting pass here, at least for local histograms.

#4 - is the port number for the localhost URL the same in every case or does it vary across invocations? Assuming I'm interpreting it correctly, the upload in #8 shows data for a single localhost port number http origin (and also for one other non-localhost https origin.)

@viv.phillips, sorry we're taking so long to address this!

Leaving at P2 because might be a bug where we corrupt the data.

wanderview@: This is definitely not urgent. If you're bored of perf investigations at some point, please look at the uploaded profile data here. I imagine all we can do at this point is to make sure we have good metrics in place.

The Needs-Feedback label remains, as we're waiting to hear about the port numbers.

Since this is on windows its possible that a file remove operation is failing due to windows file handle being open (virus scanners can do this).  This could then cause a later operation that expects the file to be gone to fail.