Background product sync crashes with fatal error

Subject: Background product sync crashes with fatal error — “Attempt to assign property ‘status’ on null” in Background.php:49 Environment: Facebook for WooCommerce: version prior to current (exact version not recorded — we have since updated) WordPress: 6.9.4 WooCommerce: latest Note: The version of Facebook for WooCommerce we were running had not been tested with our current WooCommerce version. We have since updated the plugin in hopes of resolving this. Description: The plugin’s background product sync handler crashes repeatedly with the following fatal error: PHP Fatal error: Uncaught Error: Attempt to assign property “status” on null in facebook-for-woocommerce/includes/Products/Sync/Background.php on line 49 Stack trace: #0 …/Framework/Utilities/BackgroundJobHandler.php(642): …Products\Sync\Background->process_job(NULL) #1 …/Framework/Utilities/BackgroundJobHandler.php(167): …BackgroundJobHandler->handle() #2 wp-includes/class-wp-hook.php(341): …BackgroundJobHandler->maybe_handle(”) #3 wp-admin/admin-ajax.php: do_action(‘wp_ajax_nopriv_…’) The process_job() method is being called with NULL, meaning the background job handler cannot find a valid job to process. It then tries to set ->status on the null return value and crashes. Observed behavior on our production store (June 8, 2026): 66 PHP Fatal errors from this crash throughout the day (roughly one every 15–20 minutes) Each crash attempt took 17–26 seconds of server time before dying (visible in nginx response times) All 86 HTTP 500 errors on the site that day were from this crash (admin-ajax.php?action=wc_facebook_background_product_sync) The crash loop also caused 52 cron reschedule failures (“The cron event list could not be saved”) for the facebook_for_woocommerce_5_minute_heartbeat_cron hook — the plugin couldn’t unschedule/reschedule its own cron event while crashing At one point (16:50 UTC), the cron reschedule failures fired 30 times in 11 seconds in a rapid error cascade The plugin’s wp_options scan queries (searching for wc_facebook_background_product_sync_job_% rows) also consumed 666 seconds of slow query time across 116 executions, scanning ~380,000 rows per call Additional context: We acknowledge this was likely caused by running a version of the plugin that was not tested with our current WooCommerce version. We have updated to the latest version of Facebook for WooCommerce as of today and are monitoring to see if the crash is resolved. We are filing this report in case the process_job(NULL) crash path still exists in the current version — a null check before accessing ->status would prevent the fatal error even when no valid job is found. One memory exhaustion error (512MB limit) also occurred during this period in class-wpdb.php, possibly related to the sync queries. Request: Can you confirm whether the process_job(NULL) crash has been addressed in the current version? If not, could a null guard be added in Background.php:49 so that a missing job results in a graceful skip rather than a fatal error? The wp_options scan queries using LIKE ‘wc_facebook_background_product_sync_job_%’ are expensive on large stores (~380K rows in wp_options). Could these jobs use a dedicated table or at minimum a more targeted lookup? Hi @mrtphoto , thank you for reaching out! Can you share your System Status report , and the full error stack from your debug.log using PasteBin ? Kind regards, Marija