Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Error handler context doesn't match docs #1173

Open
darkhelmet opened this issue Feb 19, 2025 · 1 comment
Open

Error handler context doesn't match docs #1173

darkhelmet opened this issue Feb 19, 2025 · 1 comment

Comments

@darkhelmet
Copy link

Trying to get this working on our existing application with Rails 8.0.1 + Sidekiq

I wanted to log the errors so I started with the Rails.error stuff (first time using that as well). I subscribe and start logging to see what I want to keep track of:

class MaintenanceTasksErrorSubscriber
  def report(error, handled:, severity:, context:, source: nil)
    return unless source == 'maintenance_tasks'

    puts "Reporting error: #{error.class.name} - #{error.message}"
    puts "Handled: #{handled}"
    puts "Severity: #{severity}"
    puts "Context: #{context}"
    puts "Source: #{source}"
  end
end

Rails.error.subscribe(MaintenanceTasksErrorSubscriber.new)

The context has a single :job key which is the ActiveJob instance of MaintenanceTasks::TaskJob. The docs suggest the context is supposed to be a bunch of other stuff.

The source is also maintenance_tasks which is different from the docs as well.

Not sure if I'm doing something wrong to get these results, or if something else.

@darkhelmet
Copy link
Author

The reason for doing what I was doing, is that I wanted to allow for multiple failures on a single run. It appears that if I report_on some errors it just sends them to reporting but doesn't track it on the run and display in the UI. It looks like that only supports a single error which then puts the run into a failed state. It would be swell to track multiple failures. I was going to try some Rails.cache shenanigans to tie all the data back to the run and then override a view to display it in the UI.

For example, I need to bulk update emails after an import, and they give me a spreadsheet of the emails we imported and what they should be updated to. But sometimes people have already updated their emails. Sometimes the email they want to use is already in use. I could silently ignore these failures to have the job succeed, but would be nice to have them displayed in the UI.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant