How Cleanup Work Continues in Restartable Batches

QCUL cleanup is restartable because deleting a large laboratory or many database/file objects can exceed one request/task execution window on real hosting.

Persisted cleanup progress

QCUL records the current lifecycle state and cleanup cursor/progress so subsequent work can continue with remaining owned objects rather than restarting the entire deletion pass.

Why batching is safer

• Reduces PHP execution-time spikes.
• Makes shared-hosting cleanup more practical.
• Allows attention/retry after a specific filesystem/database failure.
• Keeps verification tied to what was actually removed.

Administrator action

If an active removal reports Removal needs attention, fix the cause and use Retry Removal. For expired unattended cleanup, confirm the Scheduled Task is actually executing and investigate its last exit/result when progress stalls.

Scheduled-task verification

After changing or repairing How Cleanup Work Continues in Restartable Batches, verify the canonical task row in System → Scheduled Tasks: enabled/disabled state, Last Execution, Next Execution, and Last Exit Code. Registration alone does not prove the maintenance routine runs; Joomla Scheduler still needs Lazy Scheduler or server cron to trigger due work.

Community Discussion

Want to compare update-testing workflows, share practical tips, or discuss how you use this QCUL feature? Visit the QC Update Laboratory Community. For private support, bug reports, account-specific issues, or feature requests, use the QuantaCade support system.