Understanding Leftover Laboratory Directories and Database Tables

Leftover qcul-labs directories or qcul_-prefixed database tables usually indicate an interrupted/failed lifecycle or historical orphan, but they should be investigated before manual deletion.

Known owned data

An active laboratory has a run record that identifies its public ID, directory, database prefix, state, and private artifacts. Normal Remove/Expired Cleanup uses that ownership metadata to delete safely.

Orphan pattern

When a lab-looking directory/table exists without a matching active owned run, Orphan Scan reports it. That is an investigation signal, not automatic proof that the object can be deleted.

Manual cleanup precautions

• Confirm the object is not referenced by an active laboratory/history/replay/checkpoint.
• Take a database/filesystem backup before uncertain deletion.
• Check permissions/open handles if QCUL previously failed to remove it.
• Re-run Orphan Scan after controlled cleanup to confirm the finding is gone.

Scheduled-task verification

After changing or repairing Understanding Leftover Laboratory Directories and Database Tables, 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.