Cron automation & check queue

PUQ Sanctions Checker module WHMCS

Order now | Download | Community

The module uses the standard WHMCS cron. No extra cron entries are needed:

• DailyCronJob — list synchronization, mass-check scheduling, queue housekeeping;
• AfterCronJob (every cron tick, normally ~5 minutes) — check queue processing.

The check queue

Checks can be slow: the CSL API is an external HTTPS call per name, FraudRecord hashes every field 32 000 times. Running that inline during client registration or checkout can cause visible delays and timeouts. The queue solves this:

Setting	Default	Effect
Run trigger checks on the next cron (queue)	off	Registration / profile update / order checkout only add the client to the queue (instant) and the cron performs the check within ~5 minutes. Off = checks run inline as before.
Queue the mass check (process on cron)	on	The "Check all clients now" button and the scheduled mass check put clients into the queue; the cron drains it in portions. Off = the button runs realtime AJAX batches with a progress bar.
Queue items processed per cron run	50	Portion size per cron tick. Lower it when the CSL API is enabled.

Manual checks always run in real time — the Check Now button on the client card and Recheck on the Clients page never use the queue.

The queue lives in puq_sanctions_checker_queue (client, type sanctions/fraud, context, status pending → processing → done/error). The Home page shows the number of pending items; every processed portion is logged (queue_processed), failures per client are logged as check_error. Finished rows are purged after 7 days. If the queue table is unavailable, trigger checks automatically fall back to real-time so registration never breaks.

What runs daily

1. Sanctions lists synchronization — the enabled OpenSanctions mirrors (EU FSF, Canada DFATD-SEMA) are downloaded and re-imported into the local database. The files are ~2 MB each and the URLs are static, so this is fast and reliable.

2. Periodic mass check — when Periodic mass check (cron) is set to Daily, Weekly, or Monthly, the module re-screens clients (Active only or all, per the Clients to check in mass check setting) once per period — via the queue by default. The last run timestamp is shown on the Home page.

Notes

• Tickets are deduplicated, so a weekly mass check does not spam the helpdesk: a client with an already-open sanctions ticket does not get a second one.
• All cron activity is written to the module Log page (list_sync, mass_check, queue_processed events).

Manual equivalents

Everything the cron does can be triggered from the Home page: Sync sanctions lists now and Check all clients now (queued by default; with the queue disabled — realtime batches with a progress bar).