Overview

ActionScheduler_FatalErrorMonitor tracks the currently executing action and detects unexpected fatal shutdowns. If a fatal error occurs, it marks the action as failed and releases the batch claim so another runner can continue.

When monitoring is attached

During batch processing, the queue runner attaches the monitor to the current claim:

• ActionScheduler_QueueRunner::do_batch() calls $monitor->attach( $claim ) before processing actions.
• After processing, it calls $monitor->detach().

What the monitor tracks

The monitor hooks into the action lifecycle to track the current action ID:

• action_scheduler_before_execute → track_current_action()
• action_scheduler_after_execute → untrack_action()
• action_scheduler_execution_ignored → untrack_action()
• action_scheduler_failed_execution → untrack_action()

Unexpected shutdown handling

On shutdown, the monitor checks error_get_last() and, if a fatal error occurred:

• Marks the current action as failed: ActionScheduler_Store::mark_failure()
• Fires action_scheduler_unexpected_shutdown with the action ID and error data
• Releases the claim: ActionScheduler_Store::release_claim()

Fatal error types handled

The monitor treats these error types as fatal:

• E_ERROR
• E_PARSE
• E_COMPILE_ERROR
• E_USER_ERROR
• E_RECOVERABLE_ERROR

Hooks

Actions

• action_scheduler_unexpected_shutdown