[5.x]: Concurrent requests right after clearing "Control panel resources" can leave a large asset bundle permanently, partially published (`AssetManager::publishDirectory()` is not lock-protected)

[idleog]

What happened?

Claude Code found this and provided this report. I can confirm the behaviour and it fixed the problem in my project that from time to time my client lost the appearance of CKEditor fields in the backend, without any luck for me to reproduce that in a reliable way.

Description

After using Utilities → Clear Caches → "Control panel resources" (which deletes web/cpresources/* and truncates the resourcepaths table), the next control panel page load can leave a large asset bundle (in our case craftcms/ckeditor's dist/ folder, ~40MB / 302 files) permanently, partially copied — some files inside the freshly-created hash folder are missing forever, even after repeated reloads, until the folder is deleted by hand and republished in a single uncontended request.

This is not specific to a load-balanced / non-shared-filesystem setup (unlike #9738) — it reproduces on a single server with a single shared filesystem, purely from PHP-FPM handling several concurrent requests for the same page's assets.

Root cause (as far as we can tell)

\craft\helpers\App::resourcePathByUri() calls $assetManager->publish($sourcePath) whenever a requested cpresources file doesn't exist on disk yet. That eventually reaches \yii\web\AssetManager::publishDirectory():

} elseif (!empty($options['forceCopy']) || ($this->forceCopy && !isset($options['forceCopy'])) || !is_dir($dstDir)) {
    ...
    FileHelper::copyDirectory($src, $dstDir, $opts);
}

The only guard against re-copying is is_dir($dstDir). There's no lock. A browser loading one CP page typically fires off several parallel requests for different files belonging to the same bundle (JS, CSS, per-language translation files, source maps, …). If several of those requests hit _processResourceRequest() at (almost) the same moment, right after web/cpresources/ was just emptied:

1. Request A finds $dstDir missing, starts copyDirectory() (which creates the directory near-immediately, then copies ~300 files).
2. Request B, C, … (separate PHP-FPM workers, same few milliseconds) also resolve the same hash, see is_dir($dstDir) === true (A already created it), and skip copying entirely — even though A's copy is still in progress.
3. Whichever specific file B/C/… needed isn't there yet → resourcePathByUri() throws InvalidArgumentException("$filePath does not exist.") → the browser gets a 400 for that script/css/translation file.
4. Because the directory now "exists" (per the is_dir() check), no later request will ever retry the copy, even though it's incomplete. The specific missing file(s) 404/400 forever, for every subsequent request, until someone manually deletes that hash folder.

We confirmed this via storage/logs/web-*.log: multiple different files (an unrelated Craft-core bundle's locale file, and several files from the CKEditor bundle) threw "$file does not exist" within a few seconds of each other after a single cache-clear — consistent with several concurrent requests each hitting a different missing file inside the same half-copied directory, not with a single one-off failure.

Why this is easy to miss

• It doesn't reproduce reliably on a low-traffic/low-concurrency dev environment (e.g. DDEV with few PHP workers and fast local disk) — the copy usually finishes before a second concurrent request can race it there.
• It reproduces reliably on a shared-hosting environment with more PHP-FPM workers and slower disk I/O for a ~40MB/300-file bundle, immediately after using the CP's own "Clear Caches" utility.
• The resulting symptom (a large CKEditor field's toolbar/translations silently failing to load, or breaking third-party plugins that also publish sizeable bundles) looks like an unrelated JS/plugin bug rather than an infra issue, and is hard to reproduce on demand.

Workaround we're using

Setting linkAssets = true on the assetManager component (via config/app.php) avoids the issue entirely, since symlink() is a single atomic syscall with no partially-completed state:

'components' => [
    'assetManager' => function() {
        $config = \craft\helpers\App::assetManagerConfig();
        $config['linkAssets'] = true;
        return Craft::createObject($config);
    },
],

This isn't something we'd expect every Craft installation to want as a default (it exposes the real vendor path via the symlink target, and needs FollowSymLinks allowed on the web server), but it might be worth documenting as a recommended mitigation, and/or publishDirectory()/publish() could use a lock (e.g. flock() on a marker file per hash, or copy-to-temp-dir-then-atomic-rename()) so a partial copy can never be observed as "done" by a concurrent request.

Steps to reproduce

1. Use a Craft install with a reasonably large custom/plugin asset bundle (CKEditor's own bundle works well — 300+ files).
2. Utilities → Clear Caches → check only "Control panel resources" → Clear Caches.
3. Immediately open a CP page that uses that bundle (e.g. an entry with a CKEditor field), ideally with dev tools' Network tab open and throttled slightly, or just on a host with several concurrent PHP-FPM workers under some load.
4. Some of the bundle's files may 400 ("$file does not exist" in storage/logs), and keep failing on every reload afterwards.

Reproduces reliably on shared hosting (Hostpoint) with multiple PHP-FPM workers; does not reproduce on DDEV (single container, low concurrency, fast local disk)

Craft CMS version

5.10.14

PHP version

8.3

Operating system and version

No response

Database type and version

No response

Image driver and version

No response

Installed plugins and versions

[linear-code]

CMS-2364

[brandonkelly]

Thanks for reporting that! Craft 5.11.0 is out with a fix.

[idleog]

OK, sorry to bother you again, but in a diffrenet project I recognized the problem again. I asked Claude (I do not have the capacity to look into the details of this) and he came out with the following:

Ran into this again today on Craft 5.11.1, which already has the mutex fix from this issue (AssetManager::publishDirectory() in vendor/craftcms/cms/src/web/AssetManager.php). Same symptoms as before: CKEditor and CP datepicker assets (ckeditor5.js, ckeditor5.css, ckeditor5-craftcms.js, lib/translations/de.js, datepicker-de.js) throwing yii\base\InvalidArgumentException: "$file does not exist" from resourcePathByUri(), permanently, until web/cpresources/ was manually cleared.

The interesting part: storage/logs/web-*.log shows zero "Unable to acquire lock for publishing assets." warnings around the time this happened — so this wasn't the classic "two concurrent requests race past the is_dir() check" scenario the mutex fixes. The lock was apparently acquired successfully by a single request, but that request's own copy of the asset directory (CKEditor's dist/ folder, several hundred files) never fully completed — likely a PHP execution-time cutoff on shared hosting (Hostpoint), given the size of that bundle. Once the destination directory exists at all (even partially populated), AssetManager/Yii's is_dir($dstDir) check treats it as "already published" forever — no later request retries the copy, and nothing detects the directory is incomplete.

So the mutex closes the "two publishers race each other" window, but not "the one publisher that holds the lock gets cut off mid-copy" — which leaves the exact same permanently-broken state as before, just via a different trigger. linkAssets = true (symlink instead of copy, single atomic syscall) sidesteps this whole class of failure, and is probably still worth documenting as the more robust option for larger asset bundles on hosts with tighter execution-time limits — reopening or maybe worth a follow-up issue if reopening this one isn't the right move.

[brandonkelly]

@idleog I find it pretty unlikely that would happen, unless your server has extremely tight resource limits. Check max_execution_time and memory_limit.

[idleog]

@brandonkelly Thanks for your reply! Fact is, if I clear the cache for CP Resources under tools, CKEditor fields are afterwards not shown at all or not correctly. I have a lot of errors in the javascript console:
Laden fehlgeschlagen für das <script> mit der Quelle "https://www.riget.ch/cpresources/c2e493f4/translations/de.js". 220-werte-und-berufsbilder:1244:76 Laden des Moduls von "https://www.riget.ch/cpresources/c2e493f4/lib/ckeditor5.js" wurde auf Grund eines nicht freigegebenen MIME-Typs ("text/html") blockiert. 220-werte-und-berufsbilder Laden fehlgeschlagen für das Modul mit der Quelle "https://www.riget.ch/cpresources/c2e493f4/lib/ckeditor5.js". 220-werte-und-berufsbilder Laden des Moduls von "https://www.riget.ch/cpresources/c2e493f4/ckeditor5-craftcms.js" wurde auf Grund eines nicht freigegebenen MIME-Typs ("text/html") blockiert. 220-werte-und-berufsbilder Laden fehlgeschlagen für das Modul mit der Quelle "https://www.riget.ch/cpresources/c2e493f4/ckeditor5-craftcms.js". 220-werte-und-berufsbilder Laden des Moduls von "https://www.riget.ch/cpresources/c2e493f4/lib/translations/de.js" wurde auf Grund eines nicht freigegebenen MIME-Typs ("text/html") blockiert. 220-werte-und-berufsbilder Laden fehlgeschlagen für das Modul mit der Quelle "https://www.riget.ch/cpresources/c2e493f4/lib/translations/de.js". ckeditor-translations-de.js
I have CraftCMS 5.11.1 on PHP 8.3, max_execution_time=240, memory_limit: 512M
Following is from Claude Code again, I understand about half of it, but maybe it helps you?

---

Thanks for the sanity check — pulled concrete numbers from the project where this recurred this morning (2026-09-15, Craft 5.11.1, PHP 8.3) instead of relying on my earlier guess.

• Checked the actual web/FPM values (not CLI, which is misleading here) via web/.user.ini: max_execution_time = 240, memory_limit = 512M, max_input_time = 240. Not tight limits.
• Storage is NFS-mounted shared storage (.../vol/custXXX/..., ~90% capacity) — genuinely a shared filesystem even though it's "a single server."
• This morning's incident: cleared "Control panel resources," then loaded one CP entry-edit page. That single page load triggered ~26 distinct asset-bundle publishes at once (26 fresh hash folders all created within the same minute under web/cpresources/). The two largest — the CKEditor bundle (302 files / 40MB) and a CP vendor bundle including the datepicker (75 files) — both threw repeated "$file does not exist." 400s from resourcePathByUri() for about 2 minutes (07:39:54–07:42:05).
• This is production, with a client who can log in at any time, so I didn't leave it to see whether it would eventually recover on its own — I manually deleted web/cpresources/* on the server and reloaded, which republished cleanly. So same as the original report: broken until manually cleared, not self-healing.
• This happened three separate times today, all with the identical set of files (datepicker-de.js, ckeditor.css, lib/ckeditor5.js/.css, ckeditor5-craftcms.js, translations/de.js, lib/translations/de.js): 07:39:54–07:42:05, 11:41:29–11:41:37, and 12:04:05–12:05:16. Each time I manually cleared web/cpresources/* to restore the CP for the client; none of the three recovered on their own.
• Checked storage/logs/*.log for the whole incident window (and historically): zero occurrences of "Unable to acquire lock for publishing assets." anywhere. Since that's exactly what AssetManager::publishDirectory()'s mutex logs when a second requester times out waiting (5s) for the lock, this doesn't look like the classic two-copiers race the 5.11.0 mutex fix targets — it looks more like a single lock holder whose own copy of a few-hundred-file bundle is simply slow enough, on NFS-backed storage under a burst of ~26 concurrent first-time publishes, to be observed as "exists but incomplete" by anyone hitting the CP during that window.
• No PHP fatal errors (execution-time or memory) in phperrors.log for this window either, so I can't actually back up "the copy got killed by max_execution_time" as I claimed in my last comment — retracting that specific part. What the logs do show is a copy that's merely slow (on the order of minutes, not milliseconds) under load, which is_dir($dstDir) alone can't distinguish from "already finished," and which stays broken forever without manual cleanup, exactly as in the original report.

None of this needs a race between two publishers to reproduce — a single slow copy is enough, as long as anything else reads the CP while it's still running. So I'd still argue this is the same underlying gap (is_dir() isn't a "done" signal), just reached via a path the 5.11.0 fix doesn't cover. Happy to gather more (e.g. instrumenting mutex acquire/copy duration) if that'd help; linkAssets = true remains our workaround in the meantime.

[brandonkelly]

• Storage is NFS-mounted shared storage (.../vol/custXXX/..., ~90% capacity) — genuinely a shared filesystem even though it's "a single server."

This is most likely the culprit. In load-balanced environments, CP resources should be published locally to the current web server only. If a resource request comes into a different server than the one where the resource was originally published from, Craft will catch the 404, and “re”-publish the asset bundle on the current web server.

NFS mounts are notoriously slow and error-prone when multiple web servers are touching them simultaneously, so I’d strongly advise against that.

[idleog]

Thanks, Brandon! Unfortunately, I cannot change this setup on the hosting provider's server (and it's the biggest provider in Switzerland...).
I am using this additional setting in config/app.php and it does the job!

'components' => [
    'assetManager' => function() {
        $config = \craft\helpers\App::assetManagerConfig();
        $config['linkAssets'] = true;
        return Craft::createObject($config);
    },
],

Cheers, Peter