Add action-scheduler error support?

[Trisky]

Hi!
I run action scheduler for some cron jobs. https://actionscheduler.org/
It's quite a common dependency for many plugins, such as Woocommerce , wp-security-audit-log, wp-mail-smtp and others.

The issue with it is that it doesn't throw an error if it fails, it just logs it:

https://github.com/woocommerce/action-scheduler/blob/0a294e6df6ad74f40a8293c0d9e016451a21c4d5/classes/abstracts/ActionScheduler_Abstract_QueueRunner.php#L71

But... we could hook into action_scheduler_failed_execution like this:

add_action('action_scheduler_failed_execution',function($action_id, Exception $e, $context = ''){
	$client = WP_Sentry_Php_Tracker::get_instance()->get_client();
	$client->withScope(function (\Sentry\State\Scope $scope) use ($action_id,$context, $e) {
		$scope->setExtra('action_scheduler_id', $action_id);
                 $scope->setExtra('action_scheduler_context', $context);
		$client->captureException($e);
	});

}

Should I make a proper merge request for this? Or this kind of integration shouldn't belong to the plugin? Should we have a different approach here?

Currently action scheduler errors are just going to the logs without touching sentry.

[stayallive]

Hmm, this is interesting! I'd like to maybe add this but unsure how exactly. We currently don't have any of these plugin integrations but I can see the benefit of adding a few first-party ones.

I think we might be able to add this and register it based on if a plugin is installed.

But we'd also need an easy way to disable these plugin integrations if not wanted.

Or we'd need to go the opt-in route which is also a possibility but requires the user to do something even though you'd be more likely to want to enable this than not.

[Trisky]

I think we might be able to add this and register it based on if a plugin is installed.

I don't think so, action-scheduler is used by a multitude of plugins, so having a complete list of plugins would be impossible. Also, the action_scheduler_failed_execution hook is quite unique I'd say. Thus, I would just enable this by default.

---

But we'd also need an easy way to disable these plugin integrations if not wanted.

I agree on having an easy way of disabling it:
I could put this inside a condition like this, so it could be disabled by a constant

if (!(defined( 'WP_SENTRY_DISABLE_PLUGIN_INTEGRATIONS' ) && WP_SENTRY_DISABLE_PLUGIN_INTEGRATIONS){
...
}

---

I have this in production since a few days now. Works good for us.

    add_action('action_scheduler_failed_execution', function ($action_id, $e = null, $context = '') {
        $client = WP_Sentry_Php_Tracker::get_instance()->get_client();
        $client->withScope(function (\Sentry\State\Scope $scope) use ($client, $action_id, $context, $e) {
            $scope->setExtra('action_scheduler_id', $action_id);
            $scope->setExtra('action_scheduler_context', $context);
            $client->captureException($e);
        });
    }, 10, 3
    );

Should I submit a merge request?
I would add it in a new WP_Sentry_Php_Plugin_integration or just in WP_Sentry_Php_Tracker as a new private method that gets called by __contruct() . Thoughts?