Fix rake sessions:cleanup

[aaronskiba]

Please complete the following fields as applicable:

What version of the DMPRoadmap code are you running? (e.g. v2.2.0)

• 4.0.2+portage-4.0.3

Expected behaviour:

• rake sessions:cleanup should be executable
  Actual behaviour:

aaron@ubuntu:~/Documents/GitHub/roadmap
$ rake sessions:cleanup --trace
** Invoke sessions:cleanup (first_time)
** Invoke environment (first_time)
** Execute environment
** Execute sessions:cleanup
rake aborted!
NameError: uninitialized constant ActiveRecord::SessionStore
Did you mean?  SessionsController
/home/aaron/Documents/GitHub/roadmap/lib/tasks/sessions.rake:8:in `block (2 levels) in <top (required)>'
/usr/share/rvm/gems/ruby-2.7.6@dmp/gems/rake-13.1.0/lib/rake/task.rb:281:in `block in execute'
/usr/share/rvm/gems/ruby-2.7.6@dmp/gems/rake-13.1.0/lib/rake/task.rb:281:in `each'
/usr/share/rvm/gems/ruby-2.7.6@dmp/gems/rake-13.1.0/lib/rake/task.rb:281:in `execute'
/usr/share/rvm/gems/ruby-2.7.6@dmp/gems/rake-13.1.0/lib/rake/task.rb:219:in `block in invoke_with_call_chain'
/usr/share/rvm/gems/ruby-2.7.6@dmp/gems/rake-13.1.0/lib/rake/task.rb:199:in `synchronize'
/usr/share/rvm/gems/ruby-2.7.6@dmp/gems/rake-13.1.0/lib/rake/task.rb:199:in `invoke_with_call_chain'
/usr/share/rvm/gems/ruby-2.7.6@dmp/gems/rake-13.1.0/lib/rake/task.rb:188:in `invoke'
/usr/share/rvm/gems/ruby-2.7.6@dmp/gems/rake-13.1.0/lib/rake/application.rb:182:in `invoke_task'
/usr/share/rvm/gems/ruby-2.7.6@dmp/gems/rake-13.1.0/lib/rake/application.rb:138:in `block (2 levels) in top_level'
/usr/share/rvm/gems/ruby-2.7.6@dmp/gems/rake-13.1.0/lib/rake/application.rb:138:in `each'
/usr/share/rvm/gems/ruby-2.7.6@dmp/gems/rake-13.1.0/lib/rake/application.rb:138:in `block in top_level'
/usr/share/rvm/gems/ruby-2.7.6@dmp/gems/rake-13.1.0/lib/rake/application.rb:147:in `run_with_threads'
/usr/share/rvm/gems/ruby-2.7.6@dmp/gems/rake-13.1.0/lib/rake/application.rb:132:in `top_level'
/usr/share/rvm/gems/ruby-2.7.6@dmp/gems/rake-13.1.0/lib/rake/application.rb:83:in `block in run'
/usr/share/rvm/gems/ruby-2.7.6@dmp/gems/rake-13.1.0/lib/rake/application.rb:208:in `standard_exception_handling'
/usr/share/rvm/gems/ruby-2.7.6@dmp/gems/rake-13.1.0/lib/rake/application.rb:80:in `run'
/usr/share/rvm/gems/ruby-2.7.6@dmp/gems/rake-13.1.0/exe/rake:27:in `<top (required)>'
/usr/share/rvm/gems/ruby-2.7.6@dmp/bin/rake:23:in `load'
/usr/share/rvm/gems/ruby-2.7.6@dmp/bin/rake:23:in `<main>'
/usr/share/rvm/gems/ruby-2.7.6@dmp/bin/ruby_executable_hooks:22:in `eval'
/usr/share/rvm/gems/ruby-2.7.6@dmp/bin/ruby_executable_hooks:22:in `<main>'
Tasks: TOP => sessions:cleanup

[aaronskiba]

It looks like this rake task relies on gem 'activerecord-session_store', which was removed for release 3.0.4+portage-3.0.0:
2.1.3+portage-1.0.19...3.0.4+portage-3.0.0#diff-d09ea66f8227784ff4393d88a19836f321c915ae10031d16c93d67e6283ab55fL190

[aaronskiba]

Release 3.0.4+portage-3.0.5 included the following change:

config/initializers/session_store.rb is still using :cookie_store. Thus, rather than fixing this rake task, it may no longer be needed at all (Cookie is configured as Expires / Max Age: Session).

[aaronskiba]

I'm wondering if we should also have secure: true added to the session_store config? Or maybe the equivalent change should be made within the load balancer/proxy?

[nmacgreg]

For context, "at one time" there was a database table named "sessions" that grew without bound, so we created this cron job to delete old entries and keep the database clean. I remember that this would grow to millions of rows over "a few weeks or months". This affected all our Rails applications. Aaron's suggestion of the release date implies March 2022 for the transition.

A little research, to start!

First, yes, I confirm there's a crontab entry driving this:

[root@southampton ~]# crontab -l 
#Ansible: Clean sessions table, daily
5 4 * * * source /root/.bashrc && cd /var/www/sites/dmp && RAILS_ENV=staging bundle exec rake sessions:cleanup > /tmp/sessionCleanup 2>&1

...and we can see that crontab is created by Ansible, so if we plan to delete the crontab entry, I'll also need to adjust the Ansible task list to prevent it from begin recreated by a future playbook run.

I have examined the database:

• In Staging, I confirm there is still a table named sessions, c/w ~1100 entries
• In Production, I confirm there is still a table named sessions, c/w ~1000 entries
• In Production, there's convincing data from late Feb, 2022, and nothing after Mar, 2022

dmp_prod=# select * from sessions limit 5;
   id   |            session_id            |                             data                             |     created_at      |     updated_at      
--------+----------------------------------+--------------------------------------------------------------+---------------------+---------------------
 279577 | 0f3da6b542d231a21129d99308f55175 | BAh7CEkiC2xvY2FsZQY6BkVGSSIKZW5fQ0EGOwBUSSIQX2NzcmZfdG9rZW4G+| 2022-02-28 11:05:49 | 2022-02-28 11:05:49
        |                                  | OwBGSSIxSTQ2UG5QZVJ0L1BXei8rY01OcVd4Q0FaUmppakdWU0xNYzgyb0cr+|                     | 
        |                                  | R1FxZz0GOwBGSSIRcHJldmlvdXNfdXJsBjsARiIGLw==                +|                     | 
        |                                  |                                                              |                     | 
 279578 | afd8388c8faf8c700db67a87febb0d59 | BAh7CEkiC2xvY2FsZQY6BkVGSSIKZW5fQ0EGOwBUSSIQX2NzcmZfdG9rZW4G+| 2022-02-28 11:09:10 | 2022-02-28 11:09:10
        |                                  | OwBGSSIxT0tzVlRSa2VieHoxdGxSNXF5TVQxSi9VRkRYa1pHekwycmVDekNR+|                     | 
        |                                  | YXYrQT0GOwBGSSIRcHJldmlvdXNfdXJsBjsARiIGLw==                +|                     | 
        |                                  |                                                              |                     | 
dmp_prod=# select count(*) from sessions where created_at > '2022-03-31';
 count 
-------
     0
(1 row)

dmp_prod=# select count(*) from sessions where created_at > '2022-02-28';
 count 
-------
   973
(1 row)

Here's a graph demonstrating the growth rate of the database since Sept, 2024:

It's up-and-to-the-right, but linear and most importantly relatively slow, about 30Mb in 8 months, which to me seems consistent with the nature of the application.

I didn't find anything surprising here. I suggest these actions, for discussion:

• I'll visit all servers/all environments & manually remove the crontab entry
• I'll remove the stanza from the Ansible playbook that creates the cron job
• I'll scour my team's DMP documentation for mentions of this, reference this Issue, and update it to reflect the new situation
• Aaron, I think you should consider creating a DB migration to delete the old table named sessions