Some plugins interface with external services (posting messages to Slack or creating Google Calendar events for example), which can occasionally go down. When that happens, either the plugin proceeds forward and the event gets lost, or the plugin escalates an error to the framework and the user can't continue with their git action.
To address this, App::GitHooks should offer an optional asynchronous event handling system for plugins, so that plugins can submit actions to it (for actions that aren't showstoppers), and the actions can be retried automatically later if they fail.
A possible design would be using Queue::DBI with a local SQLite database. Given the added prereqs, it may be easier to create a separate event queuing module for App::GitHooks, so that App::GitHooks leverages it when it is present, or continues with its current behavior of synchronous actions when that new module isn't installed.
Some plugins interface with external services (posting messages to Slack or creating Google Calendar events for example), which can occasionally go down. When that happens, either the plugin proceeds forward and the event gets lost, or the plugin escalates an error to the framework and the user can't continue with their git action.
To address this, App::GitHooks should offer an optional asynchronous event handling system for plugins, so that plugins can submit actions to it (for actions that aren't showstoppers), and the actions can be retried automatically later if they fail.
A possible design would be using Queue::DBI with a local SQLite database. Given the added prereqs, it may be easier to create a separate event queuing module for App::GitHooks, so that App::GitHooks leverages it when it is present, or continues with its current behavior of synchronous actions when that new module isn't installed.