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.
Bootsnap speeds up the initial loading of the Rails app by:
- Optimizing the LOAD_PATH dynamically
- Caching the result of Ruby bytecode compilation
Cached data are written to `tmp/cache/bootsnap*`.
This is enabled in the default Rails app template.
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.
When running several individual tests in succession using Spring,
we get an error message:
> zeitwerk error: reloading is disabled because config.cache_classes is true
Caching classes during tests used to be recommended – but Rails 6
now recommands to reload them:
- Spring takes care of the caching for us,
- It makes zeitwerk happy.
See discussion in 65344f254c
A potential downside used to be that when running system tests using
Capybara, each web request would reload the classes, which invalidated
the model objects of the test case. But it seems to be fixed now.
when trying to access manager, if superadmin did'nt enable otp, he/she is redirected to a page to enable 2FA. When superadmin is enabling 2FA, he has to to scan a qrcode with the 2FA application client. And afterwards, the superadmin has to log in with email, password and OTP code.
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.
Rationale:
- `lib/` is supposed to contain code mostly independant from Rails;
- By default, Rails doesn't eager-load `lib/` anymore (this used to be
the case, but since a few releases).
If this commits triggers some errors, then these errors should be fixed
(rather that `lib/` being added again to the load path).
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.
