fix: stop concurrent PDFs failing with "Temporary files directory is not writable" (6.17)

[jakejackson1]

When two requests generate a PDF at the same moment and mPDF's cache directory doesn't exist yet, one of them can fail with Temporary files directory ".../tmp/mpdf/mpdf" is not writable. Both requests try to create the directory. wp_mkdir_p() returns false for the one that loses, and our Cache override passed that straight back to mPDF, which then throws for a directory that exists and is writable. A notification sent during that request goes out without its PDF.

GFPDF\Helper\Mpdf\Cache::createDirectory() now treats a directory that exists afterwards as created. This is the plugin's own code path: since 6.13.0 the scoper patch swaps mPDF's Cache for this subclass, so the fix doesn't need the mPDF fork.

This is the likely cause of the customer failures behind #1731 and #1732. Their log doesn't prove it, because no second generation was logged at the time of either failure.

Try it

Run from the WordPress root on a site with Gravity PDF active. It starts four wp eval-file processes at once, 20 times, each building the cache on a fresh directory:

U=$(wp eval 'echo wp_upload_dir()["basedir"];')
cat > "$U/gpdf-race.php" <<'PHP'
<?php
[ $base, $go ] = $args;
while ( ! file_exists( $go ) ) { usleep( 100 ); }
try { new GFPDF\Helper\Mpdf\Cache( $base . '/mpdf' ); echo "ok\n"; } catch ( Exception $e ) { echo $e->getMessage(), "\n"; }
PHP
for round in $(seq 20); do
  rm -rf "$U/gpdf-race" "$U/gpdf-go"; mkdir -p "$U/gpdf-race"
  for w in 1 2 3 4; do wp eval-file "$U/gpdf-race.php" "$U/gpdf-race" "$U/gpdf-go" 2>/dev/null & done
  sleep 2; touch "$U/gpdf-go"; wait
done | sort | uniq -c
rm -rf "$U/gpdf-race" "$U/gpdf-go" "$U/gpdf-race.php"

On 6.17.0 a share of the attempts print Temporary files directory ".../gpdf-race/mpdf" is not writable (24 of 80 on my dev site). With this branch every attempt prints ok.

Test plan

• The script above prints only ok
• PDFs still generate, and a fresh tmp/mpdf/mpdf directory is created with the parent directory's permissions
• Test_Cache passes

More info

Where the race is. wp_mkdir_p() returns early when file_exists() is true. Otherwise it walks up to an existing parent, reads its permissions and calls @mkdir( $target, $dir_perms, true ), returning false if that fails. A request that saw the directory missing, then lost the mkdir() to another request, gets false. mPDF's Cache::createBasePath() then returns false and the constructor throws. mPDF builds two of these per Mpdf instance (tempDir/mpdf and tempDir/mpdf/ttfontdata), and both go through this override.

Measured. Four concurrent wp eval-file processes building GFPDF\Helper\Mpdf\Cache on a missing directory, on the dev site (PHP 8.5, WordPress in wp-env): 16 of 40 rounds had a failure with the current override, 0 of 40 with this change applied.

Test. test_createDirectory_accepts_a_directory_created_concurrently registers a stream wrapper over the real filesystem whose mkdir() creates the directory and then reports failure, which is what the losing request sees. With the old override it throws the customer's exact message; with this change the Cache is built. The existing permission-inheritance cases still pass. Test_Cache, Test_PDF, Test_Helper_Mpdf, Test_Slow_PDF and the font tests pass locally (168 tests, 1 skipped). PHPCS is clean.

Upstream. mPDF's own Cache::createDirectory() has the same race and is tracked in GravityPDF/mpdf#203. It doesn't affect Gravity PDF once this merges, because the override replaces that method.