You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
@@ -157,6 +158,10 @@ Running Solid Queue in a separate database is recommended, but it's also possibl
157
158
158
159
You won't have multiple databases, so `database.yml` doesn't need to have primary and queue database.
159
160
161
+
### Dashboard ui setup
162
+
163
+
For viewing information about your jobs via a UI, we recommend taking a look at [mission_control-jobs](https://github.com/rails/mission_control-jobs), a dashboard where, among other things, you can examine and retry/discard failed jobs.
164
+
160
165
### Incremental adoption
161
166
162
167
If you're planning to adopt Solid Queue incrementally by switching one job at the time, you can do so by leaving the `config.active_job.queue_adapter` set to your old backend, and then set the `queue_adapter` directly in the jobs you're moving:
@@ -516,8 +521,6 @@ failed_execution.retry # This will re-enqueue the job as if it was enqueued for
516
521
failed_execution.discard # This will delete the job from the system
517
522
```
518
523
519
-
However, we recommend taking a look at [mission_control-jobs](https://github.com/rails/mission_control-jobs), a dashboard where, among other things, you can examine and retry/discard failed jobs.
520
-
521
524
### Error reporting on jobs
522
525
523
526
Some error tracking services that integrate with Rails, such as Sentry or Rollbar, hook into [Active Job](https://guides.rubyonrails.org/active_job_basics.html#exceptions) and automatically report not handled errors that happen during job execution. However, if your error tracking system doesn't, or if you need some custom reporting, you can hook into Active Job yourself. A possible way of doing this would be:
0 commit comments