Why the Current Worker Does Not Require a Separate QCTNH Callback Preflight

QCTNH 2.0.3 no longer depends on a separate QuantaCade-to-QCTNH status/control callback before each wake-up; the worker calls Joomla WebCron directly.

Current worker architecture

The production worker source states the design directly: the site registers its native WebCron endpoint and key outbound, QuantaCade stores that endpoint, and when due the worker calls that exact endpoint. There is no QuantaCade → QCTNH callback/status/control preflight in the direct-WebCron path.

How fresh state returns

After a native WebCron request finishes, the QCTNH System plugin detects that specific RunSchedulerWebcron request and sends an outbound webcron_complete check-in. This gives the central service a fresh next-due snapshot without requiring a second inbound callback.

Why control endpoints still exist

The QCTNH AJAX/control endpoint still supports signed verify/status/sync compatibility and browser heartbeat behavior. Those endpoints are not the current task-execution wake-up target.

Failure-safe scheduling

Why the Current Worker Does Not Require a Separate QCTNH Callback Preflight also sits inside bounded retry rules. A busy/ambiguous timeout can receive a short continuation, more-due work can receive a quick follow-up, while a task failure backs off instead of hammering the same failing workload. Unknown timing eventually falls back to Maximum Scheduler Delay/safety checks.

These distinctions are why Recent Activity and task/HTTP result codes matter: the worker does not treat every unsuccessful response as the same reason to retry.

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.