Feature Description

Implement a fallback CRON which does the following:

• If all user_ids within the CPT show a successful “sent” state, exit immediately. Otherwise:
• If the attempt count for any failed report is <3, then spawn another “Fallback” scheduled event for +1 hour.
• This follow-up scheduler should then attempt to repeat the steps in the “Worker” scheduled event - Report preparation, generation and sending section if any user_ids are still present in the CPT without a “sent” state.

Do not alter or remove anything below. The following sections will be managed by moderators only.

Acceptance criteria

• A "Fallback" scheduled event is defined, which is spawned by the "Initiator" (Implement “Initiator” scheduled events #11546) scheduler for +1 hour after the initial trigger date.
• The "Fallback" scheduler attempts to retry sending failed reports up to a maximum of three times.
• The "Fallback" event checks for presence of googlesitekit_email_reporting_worker_lock transient scoped to the current frequency
  • If present, it re-schedule itself (another fallback) to 20 min from now and bails further execution
  • Otherwise proceeds with the rest of the logic
• When the "Fallback" event runs, it first checks the CPT posts (googlesitekit_email_log) for the corresponding batch ID.
• The "Fallback" scheduler must exit immediately if all user IDs within the CPT show a successful sent as post status.
• If all reports are not in a sent state, the "Fallback" scheduler must check the attempt count for any failed reports.
• If the attempt count for any failed report is less than 3, the "Fallback" scheduler spawns another "Fallback" scheduled event for +1 hour.
• The "Fallback" scheduler then attempts to repeat the steps of the "Worker" scheduled event (Report preparation, generation, and sending) if any user IDs are still present in the CPT without a sent status.

Implementation Brief

• Add Google\Site_Kit\Core\Email_Reporting\Fallback_Task

  • Constructor accepts Google\Site_Kit\Core\Email_Reporting\Email_Log_Batch_Query, Google\Site_Kit\Core\Email_Reporting\Email_Reporting_Scheduler and Google\Site_Kit\Core\Email_Reporting\Worker_Task instances.
  • Add handle_fallback_action( $batch_id, $frequency, $initiator_timestamp ) method
    • Check if the batch query Email_Log_Batch_Query::is_complete() returns true to bail early - is_complete() method also verifies the number of attempts, so no further check than this is needed.
    • Otherwise, schedule next fallback - Email_Reporting_Scheduler::schedule_fallback()
    • Then Invoke Worker_Task::handle_worker_action( $batch_id, $frequency, $initiator_timestamp )
      • The Worker will handle all the steps required by AC, as well as re-schedule itself. Fallback will only handle extra check in case last Worker failed to re-schedule itself.

• Extend Google\Site_Kit\Core\Email_Reporting\Email_Reporting::register()

  • instantiate Fallback_Task
  • Hook into the Email_Reporting_Scheduler::ACTION_FALLBACK and invoke handle_callback_action from Fallback_Task instance.

• Update Email_Reporting_Scheduler::unschedule_all() to clear fallback events (wp_unschedule_hook( self::ACTION_FALLBACK )) and add the action name to Uninstallation::SCHEDULED_EVENTS so uninstall removes them.

Test Coverage

• Add basic test coverage for the Fallback_Task - verifying that it executes worker fallback when conditions are met, and bails when they are not

QA Brief

• Install WPCrontrol plugin
• Filter CRON events by googlesitekit
• You will see 3 initiator CRONs, one for each frequency:
  • 
• Run one of them, and after page reloads filter CRONs again by googlesitekit - you should see a fallback CRON (googlesitekit_email_reporting_fallback) scheduled within 59min with arguments holding the selected initiator's frequency:
  • 

Changelog entry

• Implement “Fallback” scheduled events for Email Reporting.