Introduce Rails common error reporter (#7)

Most error monitoring software claim support for `Rails.error.handle`,
but no support for `Rails.error.record`approach. But `.handle` method
swallows errors and that makes it's usage complicated in our case.

In this PR I suggest usage of `Rails.error.report`, this method is used
underneath of `Rails.error.handle`, so should be as well supported by
most error monitoring services and it fits perfectly to our use case.

If we merge thos feature, this gem will be feature complete for usage in
Cheddar's monolith application.


Relevant documentation:
- https://guides.rubyonrails.org/error_reporting.html
-
https://docs.appsignal.com/ruby/integrations/rails.html#tags-from-the-current-transaction
-
https://docs.honeybadger.io/lib/ruby/integration-guides/rails-exception-tracking/#the-rails-error-reporter

---------

Co-authored-by: Stanislav (Stas) Katkov <[email protected]>

CHANGELOG.md

@@ -2,6 +2,7 @@
 - Handler methods are now defined as instance methods for simplicity.
 - Define service_id in initializer with active_handlers, instead of handler class.
 - Use ruby 3.0 as a base for standard/rubocop, format all code according to it.
+- Introduce Rails common error reporter ( https://guides.rubyonrails.org/error_reporting.html )
 
 ## 0.1.0
 

README.md

@@ -30,6 +30,16 @@ This project depends on two dependencies:
 - Ruby >= 3.0
 - Rails >= 7.0
 
+## Error reporter
+This gem uses [Rails common error reporter](https://guides.rubyonrails.org/error_reporting.html) to report any possible error to services like Honeybadger, Appsignal, Sentry and etc. Most of those services already support this common interface, if not - it's not that hard to add this support on your own.
+
+It's possible to provide additional context for every error. e.g.
+```
+Munster.configure do |config|
+  config.error_context = { appsignal: { namespace: "webhooks" } }
+end
+```
+
 ## Development
 
 After checking out the repo, run `bin/setup` to install dependencies. Then, run `rake test` to run the tests. You can also run `bin/console` for an interactive prompt that will allow you to experiment.

lib/munster.rb

@@ -20,4 +20,5 @@ class Munster::Configuration
 
   config_accessor(:processing_job_class) { Munster::ProcessingJob }
   config_accessor(:active_handlers) { [] }
+  config_accessor(:error_context) { {} }
 end

lib/munster/controllers/receive_webhooks_controller.rb

@@ -19,8 +19,8 @@ def create
     rescue KeyError # handler was not found, so we return generic 404 error.
       render_error("Required parameters were not present in the request", :not_found)
     rescue => e
-      # TODO: add exception handler here
-      # Appsignal.add_exception(e)
+      Rails.error.set_context(**Munster.configuration.error_context)
+      Rails.error.report(e)
 
       if handler&.expose_errors_to_sender?
         error_for_sender_from_exception(e)

lib/munster/templates/munster.rb

@@ -3,5 +3,26 @@
   # Example:
   #   {:test => TestHandler, :inactive => InactiveHandler}
   config.active_handlers = {}
-  config.processing_job_class = Munster::ProcessingJob
+
+  # It's possible to overwrite default processing job to enahance it. As example if you want to add proper locking or retry mechanism.
+  #
+  # Example:
+  #
+  # class WebhookProcessingJob < Munster::ProcessingJob
+  #   def perform(webhook)
+  #     TokenLock.with(name: "webhook-processing-#{webhook.id}") do
+  #       super(webhook)
+  #     end
+  #   end
+  #
+  # This is how you can change processing job:
+  #
+  # config.processing_job_class = WebhookProcessingJob
+
+  # We're using a common interface for error reporting provided by Rails, e.g Rails.error.report. In some cases
+  # you want to enhance those errors with additional context. As example to provide a namespace:
+  #
+  # { appsignal: { namespace: "webhooks" } }
+  #
+  # config.error_context = { appsignal: { namespace: "webhooks" } }
 end