With Rails 6.1, the default queue is now the global application queue.
We want to retain our custom queues in some cases, so configure them
epxlicitely.
Follow-up of #5953.
Refactor the concerns with two goals:
- Getting closer from the way ActiveStorage adds its own hooks.
Usually ActiveStorage does this using an `Attachment#after_create`
hook, which then delegates to the blob to enqueue the job.
- Enqueuing each job only once. By hooking on `Attachment#after_create`,
we guarantee each job will be added only once.
We then let the jobs themselves check if they are relevant or not, and
retry or discard themselves if necessary.
We also need to update the tests a bit, because Rails'
`perform_enqueued_jobs(&block)` test helper doesn't honor the `retry_on`
clause of jobs. Instead it forwards the exception to the caller – which
makes the test fail.
Instead we use the inline version of `perform_enqueued_jobs()`, without
a block, which properly ignores errors catched by retry_on.
This warning re-appeared when running mailer tests:
```
DISABLE_SPRING=1 bin/rspec spec/mailers/administration_mailer_spec.rb
```
It is now fixed properly, in a way recommanded by the documentation.
Turns out we need not only to load the Job constants later, but also
not to do the same work twice – otherwise we'll get a
> ApiEntreprise::Job constant is already defined
when attempting to re-define the constant.
Fix a warning when running tests:
> DEPRECATION WARNING: Initialization autoloaded the constant DynamicSmtpSettingsInterceptor.
>
> Being able to do this is deprecated. Autoloading during initialization is going
to be an error condition in future versions of Rails.
>
> Reloading does not reboot the application, and therefore code executed during
> initialization does not run again. So, if you reload DynamicSmtpSettingsInterceptor, for example,
> the expected changes won't be reflected in that stale Class object.
>
> This autoloaded constant has been unloaded.
>
> Please, check the "Autoloading and Reloading Constants" guide for solutions.
However if we fix as recommanded, the interceptor will get added
each time the classes are reloaded. And as the actual class instance
changed after the reloading, they won't be de-duplicated – *and*
there's no way to remove the old interceptor without having a reference
to the (now-deleted) class.
Instead we load the interceptor once, and add a message about the class
not being auto-reloaded.
This removes spam in the debug console when running locally.
Removed messages look like a swarm of:
> [Tracing] Discarding <rails.request> transaction </assets/marianne.png> because it's not included in the random sample (sampling rate = 0.001)
Fixes zeitwerk complaining that the compatibility aliases loaded in an
initializer will never be reloaded.
In our case it doesn't matter that much, but it will reduce the console
spam.
As the comment states, it would be nice to load the Virus Scanner on
the Attachment (rather than the blob).
However, in order not to clobber the blob metadata, we want to run the
VirusScanner once the blob analyzer did run.
And the most direct way to detect that the blob analyzer did run is to
add an `on_update_commit` hook on the blob, as this hook will be
trigerred when saving changes to the metadata. This is what the current
solution uses.
So the current solution is almost optimal, and has a low chance of
accidentally clobbering the blob metadata – as the virus scanner is only
started when the analysis phase is finished.
ActiveStorage jobs are now moved to their own queue.
For consistency, we also move our own analysis jobs (VirusScannerJob)
on the same `:active_storage_analysis` queue.
This makes `ActionDispatch::Controller#content_type` return not only
the MIME type, but also in some circumstances the charset.
Example:
```ruby
reponse.content_type == 'text/html; charset=utf-8'
```
The MIME type-only fragment can now be accessed using `#media_type`.
Changes to the tests are not stricly necessary (because no charset is
present in the actual value), but represent the intent better.
This makes cookies more secure, by adding an automatic "purpose" field
to each cookie.
Cookies generated by Rails 5 are still forward-compatible. However
from now on the generated cookies will not be backward-compatible with
Rails 6.
When running the app using `bin/webpack-dev-server` (the external
(and fast) assets server), LiveReload is used. We need to explicitely
allow the LiveReload connections in the CSP policy.
Turns out we now need to specify the protocol explicitely.
