When running delayed_job on reboot using Consul Democracy 2.2.0, we were
getting an error:
```
`require': cannot load such file -- sassc-embedded (LoadError)
from <internal:rubygems/core_ext/kernel_require.rb>:86:in `require'
from config/application.rb:1:in
```
No idea why this gem isn't detected when running `bin/delayed_job`.
When deploying with Capistrano, we use `bundle exec bin/delayed_job`,
and that works fine, so we're using it here as well.
We had already fixed this issue in the Cosul Democracy installer [1],
but forgot to configure the Cron job to do the same.
[1] https://github.com/consuldemocracy/installer/commit/3dc69eb6
Since now generating stats (assuming the results aren't in the cache)
only takes a few seconds even when there are a hundred thousand
participants, as opposed to the several minutes it took to generate them
when we introduced the Cron job, we can simply generate the stats during
the first request to the stats page.
Note that, in order to avoid creating a temporary table when the stats
are cached, we're making sure we only create this table when we need to.
Otherwise, we could spend up to 1 second on every request to the stats
page creating a table that isn't going to be used.
Also note we're using an instance variable to check whether we're
creating a table; I tried to use `table_exists?`, but it didn't work. I
wonder whether `table_exists?` doesn't detect temporary tables.
Puma 4 is no longer maintained, and Puma 5 removed the option to run
Puma as as daemon. That means that, in order to upgrade, we need to rely
in a process monitoring tool. We're using systemd because it's installed
by default in most (all?) operating systems running Consul Democracy on
production and it's supported by both Puma and the capistrano3-puma gem.
Using systemd means Puma will be automatically started whenever it
crashes, so we no longer need the changes done in commit 40b3c9f2c and
we can now use the default tasks configuration in capistrano3-puma and
capistrano3-delayed-job.
Since Puma is also started automatically when booting the system, we
don't need a cron job to do so anymore and can remove it from the
`schedule.rb` file.
DelayedJob offers the `--monitor` (aliased as `-m`) option to create a
process that monitors the workers and restarts them when they crash.
This change implies that, in order to stop the delayed job workers, we
now need to pass the `-n` option when running `bin/delayed_job stop`:
`RAILS_ENV=production bin/delayed_job -n 2 stop`.
Note that the `sitemap:refresh` task only pings search engines at the
end, so it only does so for the `Sitemap.default_host` defined last. So
we're using the `sitemap:refresh:no_ping` task instead and pinging
search engines after creating each sitemap.
Note we're pinging search engines in staging and preproduction
environments. I'm leaving it that way because that's what we've done
until now, but I wonder whether we should only do so on production.
Since we're creating a new method to get the current url_options, we're
also using it in the dev_seeds.
This task was "temporarily" removed in commit 7b6619528. Since that was
done three and a half years ago, right after the dashboard was
introduced, I think it's time to make this "temporary" measure a bit
more permanent ;).
Our previous system to delete cached attachments didn't work for
documents because the `custom_hash_data` is different for files created
from a file and files created from cached attachments.
When creating a document attachment, the name of the file is taken into
account to calculate the hash. Let's say the original file name is
"logo.pdf", and the generated hash is "123456". The cached attachment
will be "123456.pdf", so the generated hash using the cached attachment
will be something different, like "28af3". So the file that will be
removed will be "28af3.pdf", and not "123456.pdf", which will still be
present.
Furthermore, there are times where users choose a file and then they
close the browser or go to a different page. In those cases, we weren't
deleting the cached attachments either.
So we're adding a rake task to delete these files once a day. This way
we can simplify the logic we were using to destroy cached attachments.
Note there's related a bug in documents: when editing a record (for
example, a proposal), if the title of the document changes, its hash
changes, and so it will be impossible to generate a link to that
document. Changing the way this hash is generated is not an option
because it would break links to existing files. We'll try to fix it when
moving to Active Storage.
This way we don't have to start it manually every time the server is
restarted.
Note if we start the application with `bin/rails s start -e production`,
as we'd probably want to do so this task doesn't depend on the server we
use, the application will crash when we restart it because it will be
restarted in the development environment. Maybe this issue will be fixed
in future versions of Rails and/or Puma.
Also note we're passing `2` workers to delayed job, and this number must
be the same number we use for the `delayed_job_workers` variable in
capistrano. I haven't found a way to share this variable between
whenever and capistrano.
We're generating stats every 2 hours because it's less than the time it
will take to generate stats for every process. Once stats are generated,
this task should take less than a second.
The regenerate task has been added so we can manually execute it.
Execute rake task every day to detect new actions available for not archived proposals. If there are new actions available for today, send email to proposal's author with information text, new actions available and link to proposal dashboard url.
