Why QCTNH Reports Stale Locks but Does Not Automatically Repair Them

QCTNH reports stale scheduler locks as Attention but deliberately does not clear them automatically.

Why automatic repair is risky

  • A long-running task can legitimately outlive a simplistic expectation.
  • Deleting a lock while PHP/CLI work is still active could permit overlapping execution.
  • A stale lock is often a symptom of the real problem—fatal error, timeout, killed process, or task-specific failure—and clearing it can hide that evidence.

QCTNH’s role

QCTNH computes the stale threshold from Joomla Scheduler’s own timeout setting and surfaces the count. Recovery remains an administrator/Joomla/extension responsibility so task semantics are respected.

Safe response

  1. Identify the task and expected runtime.
  2. Confirm no process is still active.
  3. Review Joomla/PHP/extension logs.
  4. Use Joomla/extension-supported recovery or a maintenance procedure appropriate to that task.
  5. Confirm the Attention state clears after the lock is legitimately resolved.

Correlate with Recent Activity

When Why QCTNH Reports Stale Locks but Does Not Automatically Repair Them looks wrong, match it with Recent Activity and the owning task’s logs at the same time. QCTNH stores event timestamps in UTC and renders them once into Joomla’s configured site timezone, making it easier to compare registration, WebCron completion, pause/resume, and origin events with Joomla/PHP logs.

That timeline is often enough to distinguish “service never reached the site” from “Joomla ran something and the task itself failed.”

Community Discussion

Want to compare scheduler workflows, share practical tips, or discuss how you use this QCTNH feature? Visit the QC Task Nudge & Health Community. For private support, bug reports, account-specific issues, or feature requests, use the QuantaCade support system.