BCrypt is used to compute Instructeur tokens, and takes a surprisingly
ong time during specs.
Reducing the complexity to speed it up.
Speeds up this spec from 0m 57s to 0m 20s.
Before, every time a password was tested, the dictionaries were parsed
again by zxcvbn.
Parsing dictionaries is slow: it may take up to ~1s. This doesn't matter
that much in production, but it makes tests very slow (because we tend
to create a lot of User records).
With this changes, the initializer tester is shared between calls, class
instances and threads. It is lazily loaded on first use, in order not to
slow down the application boot sequence.
This uses ~20 Mo of memory (only once for all threads), but makes tests
more that twice faster.
For instance, model tests go from **8m 21s** to **3m 26s**.
NB:
An additionnal optimization could be to preload the tester on
boot, before workers are forked, to take advantage of Puma copy-on-write
mechanism. In this way all forked workers would use the same cached
instance.
But:
- We're not actually sure this would work properly. What if Ruby updates
an interval ivar on the class, and this forces the OS to copy the
whole data structure in each fork?
- Puma phased restarts are not compatible with copy-on-write anyway.
So we're avoiding this optimisation for now, and take the extra 20 Mo
per worker.
These constants were defined so that existing enqueued jobs wouldn't
fail during the app upgrade.
These jobs are long gone. Let's remove the compatibility code.
This prevent a false-positive warning about a vulnerable loofah version.
We also need to ignore a new warning, about an unsafe redirect. This is
unsafe when the object given in redirect can be a hash that includes
a `:host` key. But here we are redirecting to a plain string, which is
definitely safe.
We initially did that to avoid a browser being restarted to display a
cached form with a stale CSRF token – thus provoking an
InvalidAuthenticityToken exception when the form is submitted.
But now that we use a long-lived CSRF token, we can submit forms with
a stale CSRF token successfully (because the long-lived CSRF cookie)
is still valid – so we no longer need to change the HTML cache behavior.
This fixes issues where the browser Back button wants to display a
previous POST document, but can't because of the 'no-store' setting. In
this case the browser either displays an error, or re-attempts the POST
request (without any cookies), which results in an
InvalidAuthenticityToken exception.
See `docs/adr-csrf-forgery.md` for more explanations.
Previously Sentry reported job exceptions even if a retry
strategy was specified. So we had to ignore retried job exceptions
entirely.
Since sentry-delayed-job 0.4.4, we can instead let Sentry report
job exceptions when the retry count is exhausted. Which is
exactly the behavior we want.
The key for naming the User model was missing – so the default
localization from devise-i18n was used. Unfortunately devise-i18n lacks
the plural form.
This fixes the manager dashboard displaying "User" instead of "Users".
According to Rails i18n guide, enum values should be localized
as `<model>/<enum>`, not as sub-values to the attribute.
This fixes an exception in administrate when displaying a Dossier
in the Manager.
Note: we need to change the way GraphQL attributes are generated, because
`AASM::Core::State#display_name` doesn’t honor the `model/attribute.value`
convention (and instead tries to localize as `model.attribute/value`).
So instead we lookup the localized name using ActiveRecord.
This fixes an error message on app startup about autoloaded
constants:
> DEPRECATION WARNING: Initialization autoloaded the constants ActionText::ContentHelper and ActionText::TagHelper.
The reason for this error is that the Mailjet gem forces the
immediate loading of `action_mailer`. Which leads to the
following sequence of events:
On app init, when bundler requires all the gems in the Gemfile:
- The Mailjet gem is required,
- It loads `ActionMailer::Base`.
Later, when Rails initializes itself:
- `ActionText` creates an `action_text.helpers` initializer,
- This initializer register hooks to add `ActionText` helpers
when either `action_controller_base` or `action_mailer` are loaded,
- But as `action_mailer` has already been loaded, the hook is trigerred
immediately,
- ActiveSupport::Dependencies notices `ActionText` constants do not
exist yet, auto-load them, and add the constants to
`ActiveSupport::Dependencies.autoloaded_constants`.
And even later, at the end of the Rails initialization process:
- The `:warn_if_autoloaded` initializer is run,
- It notices that `autoloaded_constants` is not empty, and prints the
warning message.
See https://github.com/mailjet/mailjet-gem/issues/213
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.
