* Increase cache TTL for social preview images
These are expensive to generate + don't change often. We can have a long cache.
Ideally, they would never expire, and get auto evicted by redis when space fills up. But I don't think a `nil` ttl is possible when a default
is set in the Rails config (see production.rb).
So I set it to a real long value. + test to guard against it accidently being changed.
* Try a cache expiration of 6.weeks as suggested by @mstruve in PR
* Improved BadgeRewarder
* Replaced find_by with find_by! in BadgeRewarder to be aware of missing badges
* Fixed and organized BadgeRewarder specs
* Use let instead of let! in BadgeRewarder tests where needed
* Add article's record key to Fastly Surrogate-Key to separate caches
After #4744 we successfully setup an auto purging system based on Fastly's surrogate key based cache and purging API.
Unfortunately this worked only in the `:show` action as comments are their own tree-based resource.
The `:index` though, is related to a single article, so without the article's record key in the `Surrogate-Key` header the first time we hit the API the result would become the value stored in Fastly's API, for all articles.
* Fix commentable mock for job spec
* Add comment.commentable.purge to the worker as well
* Add more thorough tests for commentable
* Add gem Ransack 2.3.0
* Add sorting and search to internal/reports
The UI here should probably be revisited sooner or later, I feel like
the vomit reactions might even need to be moved to their own view.
* Add system spec for internal reports search
* Remove filter for report_type
With let_it_be, we define variables that are created for the whole
context. In case we update them in an example, there might be a
discrepancy between the object and its value in the database, since the
database is cleaned between examples, but not the object itself.
This is what happened here with the `article` object. In one of the
tests, we update its organization, and in another, we reupdate it. The
problem is that the `article` object still thinks it has an
organization, but it has been cleaned in the database. So setting the
same organization id to the object doesn't trigger the SQL query, and
the article in the database still doesn't have an organization attached.
One solution is to use `reload: true` as a parameter of `let_it_be`: it
will reload the object from the database at the beginning of each test. To
make sure we don't have other dormant traps like this one, what I
propose is to either have `reload: true`, or to have the object
readonly to avoid getting to a difference between the object and its
database value.
