magento2: Corrupt Merged CSS Files

Note that due to the nature of this issue, there’s little chance that this can be replicated by somebody attempting to triage this ticket, I’m raising purely so I have something to reference with a pull request, so an engineer can review.

Preconditions (*)

1. CSS Merging Enabled (Store > Configuration > Advanced > Developer > CSS Settings > Merge CSS Files).
2. var/tmp and pub/static being on different filesystems

Steps to reproduce (*)

1. Delete the merged files from pub/static/_cache/merged/.
2. Hammer the website with concurrent traffic.

Expected result (*)

1. Website loads, looking as it should.

Actual result (*)

1. It’s possible that the merged file is incomplete, entirely breaking the design of the site until such time as the merged file is removed or a change results in a different filename. The effected pages are at best, very ugly and at worse, entirely non-usable, as elements you need to interact with may overlap, etc.

Work was previously done to improve this issue in commit 1b46c966d416ec27ca0891be654b69d7345da2d6, there is however an edge case. The previous commit generates randomly named files, so that two concurrent generation requests don’t start writing to the same file, causing one request to copy the partly generated file from the other request. This is a good idea, as each concurrent generation of the file creates its own file. Once generated, the file is moved from the temporary location to the target location using a rename command.

The rename command is normally atomic, meaning the target file is never a partially complete file. The edge case is that if the temp directory and the static directory are not on the same filesystem, the rename command is no longer atomic. This means that during the rename from the temporary path to the static directory, the file can be served partially complete and cached in the CDN / browser cache.

The only solution I’m aware of is to have the temporary file created in the same directory as the target path. Pull request to follow.

---

Please provide Severity assessment for the Issue as Reporter. This information will help during Confirmation and Issue triage processes.

• Severity: S0 - Affects critical data or functionality and leaves users without workaround.
• Severity: S1 - Affects critical data or functionality and forces users to employ a workaround.
• Severity: S2 - Affects non-critical data or functionality and forces users to employ a workaround.
• Severity: S3 - Affects non-critical data or functionality and does not force users to employ a workaround.
• Severity: S4 - Affects aesthetics, professional look and feel, “quality” or “usability”.