26 |
27 |
28 | Solid Errors is a DB-based, app-internal exception tracker for Rails applications, designed with simplicity and performance in mind. It uses the new [Rails error reporting API](https://guides.rubyonrails.org/error_reporting.html) to store uncaught exceptions in the database, and provides a simple UI for viewing and managing exceptions.
29 |
30 | > [!WARNING]
31 | > The current point release of Rails (7.1.3.2) has a bug which severely limits the utility of Solid Errors. Exceptions raised during a web request *are not* reported to Rails' error reporter. There is a fix in the `main` branch, but it has not been released in a new point release. As such, Solid Errors is **not** production-ready unless you are running Rails from the `main` branch or until a new point version is released and you upgrade.
32 | > The original bug report can be found [here](https://github.com/rails/rails/issues/51002) and the pull request making the fix is [here](https://github.com/rails/rails/pull/51050). I will try to backport the fix into the gem directly, but I haven't quite figured it out yet.
33 |
34 |
35 | ## Installation
36 |
37 | Install the gem and add to the application's Gemfile by executing:
38 | ```bash
39 | $ bundle add solid_errors
40 | ```
41 |
42 | If bundler is not being used to manage dependencies, install the gem by executing:
43 | ```bash
44 | $ gem install solid_errors
45 | ```
46 |
47 | After installing the gem, run the installer:
48 | ```bash
49 | $ rails generate solid_errors:install
50 | ```
51 |
52 | This will create the `db/errors_schema.rb` file.
53 |
54 | You will then have to add the configuration for the errors database in `config/database.yml`. If you're using sqlite, it'll look something like this:
55 |
56 | ```yaml
57 | production:
58 | primary:
59 | <<: *default
60 | database: storage/production.sqlite3
61 | errors:
62 | <<: *default
63 | database: storage/production_errors.sqlite3
64 | migrations_paths: db/errors_migrate
65 | ```
66 |
67 | ...or if you're using MySQL/PostgreSQL/Trilogy:
68 |
69 | ```yaml
70 | production:
71 | primary: &primary_production
72 | <<: *default
73 | database: app_production
74 | username: app
75 | password: <%= ENV["APP_DATABASE_PASSWORD"] %>
76 | errors:
77 | <<: *primary_production
78 | database: app_production_errors
79 | migrations_paths: db/errors_migrate
80 | ```
81 |
82 | > [!NOTE]
83 | > Calling `bin/rails solid_errors:install` will automatically add `config.solid_errors.connects_to = { database: { writing: :errors } }` to `config/environments/production.rb`, so no additional configuration is needed there (although you must make sure that you use the `errors` name in `database.yml` for this to match!). But if you want to use Solid Errors in a different environment (like staging or even development), you'll have to manually add that `config.solid_errors.connects_to` line to the respective environment file. And, as always, make sure that the name you're using for the database in `config/database.yml` matches the name you use in `config.solid_errors.connects_to`.
84 |
85 | Then run `db:prepare` in production to ensure the database is created and the schema is loaded.
86 |
87 | Then mount the engine in your `config/routes.rb` file:
88 | ```ruby
89 | authenticate :user, -> (user) { user.admin? } do
90 | mount SolidErrors::Engine, at: "/solid_errors"
91 | end
92 | ```
93 |
94 | > [!NOTE]
95 | > Be sure to [secure the dashboard](#authentication) in production.
96 |
97 | ## Usage
98 |
99 | All exceptions are recorded automatically. No additional code required.
100 |
101 | Please consult the [official guides](https://guides.rubyonrails.org/error_reporting.html) for an introduction to the error reporting API.
102 |
103 | There are intentionally few features; you can view and resolve errors. That’s it. The goal is to provide a simple, lightweight, and performant solution for tracking exceptions in your Rails application. If you need more features, you should probably use a 3rd party service like [Honeybadger](https://www.honeybadger.io/), whose MIT-licensed [Ruby agent gem](https://github.com/honeybadger-io/honeybadger-ruby) provided a couple of critical pieces of code for this project.
104 |
105 | ### Manually reporting an Error
106 |
107 | Errors can be added to Solid Errors via the [Rails error reporter](https://guides.rubyonrails.org/error_reporting.html).
108 |
109 | There are [three ways](https://guides.rubyonrails.org/error_reporting.html#using-the-error-reporter) you can use the error reporter:
110 |
111 | `Rails.error.handle` will report any error raised within the block. It will then swallow the error, and the rest of your code outside the block will continue as normal.
112 |
113 | ```ruby
114 | result = Rails.error.handle do
115 | 1 + '1' # raises TypeError
116 | end
117 | result # => nil
118 | 1 + 1 # This will be executed
119 | ```
120 |
121 | `Rails.error.record` will report errors to all registered subscribers and then re-raise the error, meaning that the rest of your code won't execute.
122 |
123 | ```ruby
124 | Rails.error.record do
125 | 1 + '1' # raises TypeError
126 | end
127 | 1 + 1 # This won't be executed
128 | ```
129 |
130 | You can also manually report errors by calling `Rails.error.report`:
131 |
132 | ```ruby
133 | begin
134 | # code
135 | rescue StandardError => e
136 | Rails.error.report(e)
137 | end
138 | ```
139 |
140 | All 3 reporting APIs (`#handle`, `#record`, and `#report`) support the following options, which are then passed along to all registered subscribers:
141 |
142 | * `handled`: a Boolean to indicate if the error was handled. This is set to `true` by default. `#record` sets this to `false`.
143 | * `severity`: a Symbol describing the severity of the error. Expected values are: `:error`, `:warning`, and `:info`. `#handle` sets this to `:warning`, while `#record` sets it to `:error`.
144 | * `context`: a Hash to provide more context about the error, like request or user details
145 | * `source`: a String about the source of the error. The default source is `"application"`. Errors reported by internal libraries may set other sources; the Redis cache library may use "redis_cache_store.active_support", for instance. Your subscriber can use the source to ignore errors you aren't interested in.
146 |
147 | ```ruby
148 | Rails.error.handle(context: { user_id: user.id }, severity: :info) do
149 | # ...
150 | end
151 | ```
152 |
153 | ### Configuration
154 |
155 | You can configure Solid Errors via the Rails configuration object, under the `solid_errors` key. Currently, 6 configuration options are available:
156 |
157 | * `connects_to` - The database configuration to use for the Solid Errors database. See [Database Configuration](#database-configuration) for more information.
158 | * `username` - The username to use for HTTP authentication. See [Authentication](#authentication) for more information.
159 | * `password` - The password to use for HTTP authentication. See [Authentication](#authentication) for more information.
160 | * `sends_email` - Whether or not to send emails when an error occurs. See [Email notifications](#email-notifications) for more information.
161 | * `email_from` - The email address to send a notification from. See [Email notifications](#email-notifications) for more information.
162 | * `email_to` - The email address(es) to send a notification to. See [Email notifications](#email-notifications) for more information.
163 | * `email_subject_prefix` - Prefix added to the subject line for email notifications. See [Email notifications](#email-notifications) for more information.
164 |
165 | ### Database Configuration
166 |
167 | `config.solid_errors.connects_to` takes a custom database configuration hash that will be used in the abstract `SolidErrors::Record` Active Record model. This is required to use a different database than the main app ([but the primary database can also be used](#single-database-configuration)). For example:
168 |
169 | ```ruby
170 | # Use a single separate DB for Solid Errors
171 | config.solid_errors.connects_to = { database: { writing: :solid_errors, reading: :solid_errors } }
172 | ```
173 |
174 | or
175 |
176 | ```ruby
177 | # Use a separate primary/replica pair for Solid Errors
178 | config.solid_errors.connects_to = { database: { writing: :solid_errors_primary, reading: :solid_errors_replica } }
179 | ```
180 |
181 | #### Single Database Configuration
182 |
183 | Running Solid Errors in a separate database is recommended, but it's also possible to use one single database for both the app and the errors. Just follow these steps to add errors to the primary database:
184 |
185 | 1. Copy the contents of `db/errors_schema.rb` into a normal migration and delete `db/errors_schema.rb`
186 | 2. Remove `config.solid_errors.connects_to` from your configuration files.
187 | 3. Migrate your database.
188 |
189 | You won't have multiple databases, so `database.yml` doesn't need to have the errors database configuration.
190 |
191 | #### Authentication
192 |
193 | Solid Errors does not restrict access out of the box. You must secure the dashboard yourself. However, it does provide basic HTTP authentication that can be used with basic authentication or Devise. All you need to do is setup a username and password.
194 |
195 | There are two ways to setup a username and password. First, you can use the `SOLIDERRORS_USERNAME` and `SOLIDERRORS_PASSWORD` environment variables:
196 |
197 | ```ruby
198 | ENV["SOLIDERRORS_USERNAME"] = "frodo"
199 | ENV["SOLIDERRORS_PASSWORD"] = "ikeptmysecrets"
200 | ```
201 |
202 | Second, you can set the `SolidErrors.username` and `SolidErrors.password` variables in an initializer:
203 |
204 | ```ruby
205 | # Set authentication credentials for Solid Errors
206 | config.solid_errors.username = Rails.application.credentials.solid_errors.username
207 | config.solid_errors.password = Rails.application.credentials.solid_errors.password
208 | ```
209 |
210 | Either way, if you have set a username and password, Solid Errors will use basic HTTP authentication. If you have not set a username and password, Solid Errors will not require any authentication to view the dashboard.
211 |
212 | If you use Devise for authentication in your app, you can also restrict access to the dashboard by using their `authenticate` constraint in your routes file:
213 |
214 | ```ruby
215 | authenticate :user, -> (user) { user.admin? } do
216 | mount SolidErrors::Engine, at: "/solid_errors"
217 | end
218 | ```
219 |
220 | #### Email notifications
221 |
222 | Solid Errors _can_ send email notifications whenever an error occurs, if your application has ActionMailer already properly setup to send emails. However, in order to activate this feature you must define the email address(es) to send the notifications to. Optionally, you can also define the email address to send the notifications from (useful if your email provider only allows emails to be sent from a predefined list of addresses) or simply turn off this feature altogether. You can also define a subject prefix for the email notifications to quickly identify the source of the error.
223 |
224 | There are two ways to configure email notifications. First, you can use environment variables:
225 |
226 | ```ruby
227 | ENV["SOLIDERRORS_SEND_EMAILS"] = true # defaults to false
228 | ENV["SOLIDERRORS_EMAIL_FROM"] = "errors@myapp.com" # defaults to "solid_errors@noreply.com"
229 | ENV["SOLIDERRORS_EMAIL_TO"] = "devs@myapp.com" # no default, must be set
230 | ENV["SOLIDERRORS_EMAIL_SUBJECT_PREFIX"] = "[Application name][Environment]" # no default, optional
231 | ```
232 |
233 | Second, you can set the values via the configuration object:
234 |
235 | ```ruby
236 | # Set authentication credentials and optional subject prefix for Solid Errors
237 | config.solid_errors.send_emails = true
238 | config.solid_errors.email_from = "errors@myapp.com"
239 | config.solid_errors.email_to = "devs@myapp.com"
240 | config.solid_errors.email_subject_prefix = "[#{Rails.application.name}][#{Rails.env}]"
241 | ```
242 |
243 | If you have set `send_emails` to `true` and have set an `email_to` address, Solid Errors will send an email notification whenever an error occurs. If you have not set `send_emails` to `true` or have not set an `email_to` address, Solid Errors will not send any email notifications.
244 |
245 | ### Examples
246 |
247 | There are only two screens in the dashboard.
248 |
249 | * the index view of all unresolved errors:
250 |
251 | 
252 |
253 | * and the show view of a particular error:
254 |
255 | 
256 |
257 | ### Usage with API-only Applications
258 |
259 | If your Rails application is an API-only application (generated with the `rails new --api` command), you will need to add the following middleware to your `config/application.rb` file in order to use the dashboard UI provided by Solid Errors:
260 |
261 | ```ruby
262 | # /config/application.rb
263 | config.middleware.use ActionDispatch::Cookies
264 | config.middleware.use ActionDispatch::Session::CookieStore
265 | config.middleware.use ActionDispatch::Flash
266 | ```
267 |
268 | ### Overwriting the views
269 |
270 | You can find the views in [`app/views`](https://github.com/fractaledmind/solid_errors/tree/main/app/views).
271 |
272 | ```bash
273 | app/views/
274 | ├── layouts
275 | │ └── solid_errors
276 | │ ├── _style.html
277 | │ └── application.html.erb
278 | └── solid_errors
279 | ├── error_mailer
280 | │ ├── error_occurred.html.erb
281 | │ └── error_occurred.text.erb
282 | ├── errors
283 | │ ├── _actions.html.erb
284 | │ ├── _error.html.erb
285 | │ ├── _row.html.erb
286 | │ ├── index.html.erb
287 | │ └── show.html.erb
288 | └── occurrences
289 | ├── _collection.html.erb
290 | └── _occurrence.html.erb
291 | ```
292 |
293 | You can always take control of the views by creating your own views and/or partials at these paths in your application. For example, if you wanted to overwrite the application layout, you could create a file at `app/views/layouts/solid_errors/application.html.erb`. If you wanted to remove the footer and the automatically disappearing flash messages, as one concrete example, you could define that file as:
294 |
295 | ```erb
296 |
297 |
298 |
299 | Solid Errors
300 | <%= csrf_meta_tags %>
301 | <%= csp_meta_tag %>
302 |
303 | <%= render "layouts/solid_errors/style" %>
304 |
305 |
306 |
307 | <%= content_for?(:content) ? yield(:content) : yield %>
308 |
309 |
310 |
311 | <% if notice.present? %>
312 |
313 | <%= notice %>
314 |
315 | <% end %>
316 |
317 | <% if alert.present? %>
318 |
6 |
7 |
8 | 
9 |
10 |
11 | 
12 |
13 |
14 | 
15 |
16 |
17 | 
18 |
19 |
20 | 
21 |
22 |
23 | 
24 |
25 | 
335 |
336 |