Title: WP Offload SES queue not processing when WP-CLI memory_limit is -1 Last modified: April 28, 2026 --- # WP Offload SES queue not processing when WP-CLI memory_limit is -1 * [tomjenx](https://wordpress.org/support/users/tomjenx/) * (@tomjenx) * [1 month ago](https://wordpress.org/support/topic/wp-offload-ses-queue-not-processing-when-wp-cli-memory_limit-is-1/) * Hi Delicious Brains support, * We’re using WP Offload SES Lite with AWS SES for WordPress transactional email. On one site, real emails were being added to the Offload SES queue but were not being sent when WP-Cron was run via WP-CLI. * The SES domain, DKIM, IAM credentials, and region all appear to be correct. The Offload SES test email sends successfully through AWS SES and has valid SES/DKIM headers. However, normal WordPress emails were sitting in the queue. * Site details: - WordPress: 6.9.4 - PHP: 8.4.18 - WP Offload SES Lite: 1.8.0 - Server: Nginx / SpinupWP - AWS SES region: eu-west-1 - WP-Cron disabled in WordPress and run via server cron using WP-CLI - WP-CLI memory_limit: -1 * The queue event existed and was running: * ```wp-block-code wp cron event list | grep -i ses ``` * showed: * ```wp-block-code deliciousbrains_wp_offload_ses_queue_connection now 1 minute ``` * Manually running it completed successfully: * ```wp-block-code wp cron event run deliciousbrains_wp_offload_ses_queue_connection ``` * Output: * ```wp-block-code Executed the cron event 'deliciousbrains_wp_offload_ses_queue_connection' in 0.01s. Success: Executed a total of 1 cron event. ``` * However, the queued emails remained queued. * The database showed that the emails and jobs existed and were available: * ```wp-block-code SELECT email_id, email_status, email_created, email_sent FROM wp_oses_emails ORDER BY email_id DESC LIMIT 10; ``` * Example output before the fix: * ```wp-block-code email_id email_status email_created email_sent 81 queued 2026-04-28 09:30:39 NULL 80 queued 2026-04-28 09:30:35 NULL 79 queued 2026-04-28 09:26:08 NULL ``` * And: * ```wp-block-code SELECT COUNT(*) AS total_jobs, SUM(reserved_at IS NULL) AS unreserved_jobs, SUM(available_at <= UTC_TIMESTAMP()) AS available_jobs FROM wp_oses_jobs; ``` * returned: * ```wp-block-code total_jobs unreserved_jobs available_jobs 3 3 3 ``` * The worker lock was not set: * ```wp-block-code wp transient get deliciousbrains_wp_offload_ses_queue_connection --network ``` * returned: * ```wp-block-code Warning: Transient with key "deliciousbrains_wp_offload_ses_queue_connection" is not set. ``` * We then checked the WP-CLI memory state: * ```wp-block-code wp eval ' echo "memory_limit: " . ini_get("memory_limit") . "\n"; echo "memory_get_usage true: " . memory_get_usage(true) . "\n"; echo "80 percent threshold: " . (wp_convert_hr_to_bytes(ini_get("memory_limit")) * 0.8) . "\n"; ' ``` * Output: * ```wp-block-code memory_limit: -1 memory_get_usage true: 100466688 80 percent threshold: -0.8 ``` * We added a temporary filter to log the result of the WP Queue memory check: * ```wp-block-code add_filter('wp_queue_cron_memory_exceeded', function ($exceeded) { error_log('Offload SES queue memory_exceeded original value: ' . var_export($exceeded, true)); error_log('Offload SES memory usage: ' . memory_get_usage(true)); error_log('Offload SES memory limit: ' . ini_get('memory_limit')); return false; }, 10, 1); ``` * When the queue event was run again, the logs showed: * ```wp-block-code Offload SES queue memory_exceeded original value: true Offload SES memory usage: 102563840 Offload SES memory limit: -1 ``` * Immediately after returning `false` from that filter, the queued emails were sent successfully: * ```wp-block-code email_id email_status email_created email_sent 81 sent 2026-04-28 09:30:39 2026-04-28 10:03:04 80 sent 2026-04-28 09:30:35 2026-04-28 10:03:04 79 sent 2026-04-28 09:26:08 2026-04-28 10:03:04 ``` * It looks like the bundled WP Queue memory check may not handle PHP’s unlimited memory setting correctly. In `vendor/WP-Queue/Cron.php`, the memory check appears to multiply the result of `get_memory_limit()` by `0.8`. When `ini_get('memory_limit')` is `-1`, this results in a negative threshold, so `memory_get_usage(true)` is always greater than the calculated limit and the queue worker exits before processing jobs. * The relevant behaviour appears to be: * ```wp-block-code memory_limit = -1 threshold = -0.8 memory_get_usage(true) >= -0.8 memory_exceeded = true ``` * So the queue worker runs, but the processing loop never actually processes the available jobs. * As a temporary workaround we have added this mu-plugin: * ```wp-block-code