Upgrade dependencies and add support for Rails 7.2 and 8.0

[rzane]

Summary

Provide a general description of the code changes in your pull
request... were there any bugs you had fixed? If so, mention them. If
these bugs have open GitHub issues, be sure to tag them here as well,
to keep the conversation linked together.

• Changes required_ruby_version to >= 3.2
• Changes Rails version support to >= 7.0, < 8.1
• Removes unnecessary files and configuration from spec/dummy
• Removes unnecessary >= 5.2 checks
• Commits lockfiles, since that's what we do nowadays
• Runs CI against Ruby 3.2, 3.3, and 3.4

Other Information

If there's anything else that's important and relevant to your pull
request, mention that information here. This could include
benchmarks, or other information.

Thanks for contributing to Journaled!

/domain @Betterment/journaled-owners
/platform @jmileham @coreyja @ceslami @danf1024

[samandmoore]

I'm stale on some of this stuff. I thought this was added in rails 8. But am I reading this correctly? We want to only add this in rails less than 8?

[rzane]

This is really complicated and confusing. This spec was failing Rails 7.2, but passing for all other versions (including 8.0).

A feature was added in Rails 7.2 that would enqueue jobs after the transaction commits. There were three possible configurations for this flag (see here):

• :default - Defer to the adapter's #enqueue_after_transaction_commit? method
• :never - Don't wait until after commit.
• :always - Always wait until after commit.

In our test suite, we use the :test adapter, which returns true from enqueue_after_transaction_commit?. Delayed, for example, returns false.

In Rails 8.0, they decided this was actually a pretty dangerous configuration. They stopped delegating to the adapter -- :default is now the same as :never.

So, in summary, we'll set this to :never to make 7.2 behave the same as all other versions.

[rzane]

I made a change to explain why this exists and make sure it doesn't apply to versions < 7.2.

[rzane]

We could also add a runtime check to ensure that ActiveJob is not configured to enqueue after commit, but it would be complicated.

module Journaled
  if ActiveJob.gem_version >= Gem::Version.new('8.0')
    def self.enqueue_after_transaction_commit?
      job_base_class_name.constantize.enqueue_after_transaction_commit.in?([true, :always])
    end
  elsif ActiveJob.gem_version >= Gem::Version.new('7.2')
    def self.enqueue_after_transaction_commit?
      job_base_class = job_base_class_name.constantize

      case job_base_class.enqueue_after_transaction_commit
      when :default
        job_base_class.queue_adapter.enqueue_after_transaction_commit?
      when :always
        true
      else
        false
      end
    end
  else
    def self.enqueue_after_transaction_commit?
      false
    end
  end
end

[samandmoore]

Oh wow. Thanks for explaining. Also, it's nice to know I'm not entirely out of the loop. Glad I asked.

[samandmoore]

I defer to @smudge on whether we need a runtime check for this.

My gut is that we're okay without it. But he has a far better grasp of the risks.

[smudge]

Yeah, I remember going down this rabbit hole a while back and then seeing when they realized it was unsafe & changed the behavior.

Within the delayed gem we do have a runtime check at time of enqueue .

That only applies to those using delayed, but Journaled does have a runtime check to make sure you're at least using a DB-backed adapter.

I wouldn't be opposed to doing something at runtime that would simply raise if you're using a DB-backed adapter & are enqueuing after commit -- like, rather than fixing your config, we'd just blow up tell you that your config is unsafe -- but ultimately that might just look like the check we already have in the delayed gem.

[samandmoore]

domainlgtm

[rzane]

Since I'm dropping old Rubies/Rails versions, should I bump the major?

[smudge]

platform LGTM -- left a note here -- i'd be fine with a runtime guard that raises if it detects an unsafe config. (we already raise if we detect an unsafe queue adapter.) But I don't think it's critical to us since we already have that enqueue-time check in the delayed gem.

[smudge]

@rzane Good call - from a SemVer perspective I think the answer is yes, strictly speaking.

Invalidated by push of e276b8f

[rzane]

Version bumped 👍

For simplicity sake, I chose to make enqueue_after_transaction_commit configuration a documentation concern.

[smudge]

platform LGTM

[smudge]

domain LGTM