How Duplicate QCUL Scheduled Tasks Are Handled

When multiple rows represent the same QCUL operational task, the integrity service selects one canonical row and disables the extras rather than allowing duplicate cleanup/safety work to run concurrently.

Canonical selection

Rows are ordered so an enabled row is preferred, then the lowest task ID. QCUL repairs that row’s expected type/title/note/rules where needed.

Duplicate handling

Additional matching rows are set to disabled and receive a note explaining that the selected canonical task remains authoritative.

Why duplicates are risky

Duplicate maintenance tasks can cause redundant scans/cleanup work, confusing task history, and concurrency pressure. If you see duplicates, let QCUL integrity repair disable them and then verify one intended canonical schedule in Joomla Scheduled Tasks.

After duplicate repair

Check that only the chosen canonical task is enabled and that its schedule is the one you intend to keep. Disabled duplicate rows receive a QCUL note identifying them as non-authoritative; do not re-enable every duplicate simply because they share the expected title/type.

Scheduled-task verification

After changing or repairing How Duplicate QCUL Scheduled Tasks Are Handled, 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.