Timeout when purging Cache via Backend

[Chrico]

When purging the WP-Stash-Cache via Backend (AdminBar) in a large Multisite, i can see following error message:

Fatal error: Maximum execution time of 30 seconds exceeded in /html/????/deployments/releases/2/vendor/tedivm/stash/src/Stash/Utilities.php on line 153

---

• PHP: 7.2.x FPM
• WP_STASH_DRIVER: \Stash\Driver\FileSystem

---

The default timeout of php should be either set to 0 (endless) or better, we should purge the cache partially in background via e.G. Cron by splitten up the folder into multiple Crons to delete those.

[Biont]

@Chrico Partial flush is probably hard/impossible to pull off because it's an extremely backend-specific problem. Ultimately, we can't do what Stash can't do, and $pool->clear() is all there is.

However, wp_schedule_event sounds reasonable, especially since you mention it's in a large multisite, where the backend might be slow and eating into the max_execution_time more than welcome. So deferring the cache flush to a more or less isolated call sounds like it could help here.

[Biont]

#14 Does not directly address this issue at its core, but should help avoid situations where it would be neccessary to do a partial flush. The problem was that the FileSystem-driver was filling up the disk without restriction and a flush was taking far longer than PHP allows.
Now that we're performing recurring purge tasks, the FileSystem-driver should clean up after itself and flushing should be possible even from the admin bar. Can you maybe share your experiences after some time on v3.1.0 of WP Stash, @Chrico ?

wp_schedule_single_event would still be a way to gain a couple of extra seconds on regular installs and ensure the task can run forever on more sophisticated installs. But the obvious downside is that there is no (immediate) feedback about whether (or when) the task is actually executed.

[Chrico]

We could still use the wp_schedule_single_event and showing a admin notices when the job is still running (setting an option when the job start, which will be removed afterwards).

But #14 should have fixed that, even if we invalidate cache objects which shouldn't be invalidated automatically.

[Biont]

showing a admin notices when the job is still running (setting an option when the job start, which will be removed afterwards).

My thoughts exactly. I'm just hesitant to add all this extra logic when it may not really be needed in the end. The only thing that really bugs me now is that if it happens, we get a white screen of death with a 500.
Maybe a good first step would be to turn this into an AJAX or REST call? Then we could at least handle this gracefully

[Biont]

Hm.. We could use wp_next_scheduled instead of an option to check if a cache flush is scheduled. If there is a job, we display a notice.