Skip to content

Require rails >= 7 #458

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
adamruzicka merged 3 commits into from
Nov 18, 2025
+9 −5
Merged

Require rails >= 7 #458

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
a3f86f8
Require rails >= 7
adamruzicka Nov 12, 2025
4442e06
Deal with activesupport time extensions
adamruzicka Nov 12, 2025
49e57a6
Workaround for older sidekiq
adamruzicka Nov 12, 2025
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 1 addition & 1 deletion Gemfile
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -33,7 +33,7 @@ end
group :rails do
gem 'daemons'
gem 'logging'
gem 'rails', '>= 4.2.9', '< 7'
gem 'rails', '>= 7', '< 8'
end

group :telemetry do
Expand Down
2 changes: 1 addition & 1 deletion lib/dynflow/executors/sidekiq/core.rb
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -13,7 +13,7 @@
config[:semi_reliable_fetch] = true
Sidekiq::ReliableFetch.setup_reliable_fetch!(config)
end
::Sidekiq.strict_args!(false)
::Sidekiq.strict_args!(false) if ::Sidekiq.respond_to?(:strict_args!)
Copy link

@ofedoren ofedoren Nov 18, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why do we need that check?

Also, looking at what it does, shouldn't we put it something like Rails.dev? || Rails.test? ? :warn : false? Or we don't want to migrate to the strings only args?

Copy link
Contributor Author

@adamruzicka adamruzicka Nov 18, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why do we need that check?

Due to some combination of transitive dependencies, early version of sidekiq-6 was being pulled in in tests, but this early version didn't implement Siedkiq.strict_args yet. Since we try to support the entire sidekiq 6 line, this felt like the easiest way out

Or we don't want to migrate to the strings only args?

Doing this properly (not trying to send non-json-native things anywhere) would be a major undertaking as that would have to happen both in dynflow's internals as well as in the user code being managed by dynflow. A hacky way would be to extend our own serialization layer to serialize even the things which previously didn't need to be.

shouldn't we put it something like Rails.dev? || Rails.test? ? :warn : false

While we could do that, I'm not aware of anyone who would be running sidekiq in development?

Copy link

@ofedoren ofedoren Nov 18, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for the explanation!

Copy link
Contributor Author

@adamruzicka adamruzicka Nov 18, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A hacky way would be to extend our own serialization layer to serialize even the things which previously didn't need to be.

Something like https://github.com/Dynflow/dynflow/compare/master...adamruzicka:sidekiq-json?expand=1 maybe? But I can't say I like it

Copy link

@ofedoren ofedoren Nov 18, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's interesting, and at the first glance it should cover everything. It's just that strict_args without an argument will raise an error, so it's kinda dangerous to just rely on "it should". Maybe warn for the starters and if we won't see any, then just drop it in the future?


module Dynflow
module Executors
Expand Down
4 changes: 4 additions & 0 deletions lib/dynflow/extensions/msgpack.rb
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -16,6 +16,10 @@ def to_msgpack(out = ''.dup)
::MessagePack::DefaultFactory.register_type(0x00, Time, packer: MessagePack::Time::Packer, unpacker: MessagePack::Time::Unpacker)

begin
# time_with_zone added a deprecation warning in 7.1.0 which we need to account for
# it was removed again in 7.2.0
require 'active_support/deprecation'
require 'active_support/deprecator'
require 'active_support/time_with_zone'
unpacker = ->(payload) do
tv = MessagePack::Timestamp.from_msgpack_ext(payload)
Expand Down
6 changes: 3 additions & 3 deletions test/extensions_test.rb
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -1,15 +1,15 @@
# frozen_string_literal: true

require_relative 'test_helper'
require 'active_support/time'
require 'active_support/all'

module Dynflow
module ExtensionsTest
describe 'msgpack extensions' do
before do
Thread.current[:time_zone] = ActiveSupport::TimeZone['Europe/Prague']
Time.zone = ActiveSupport::TimeZone['Europe/Prague']
end
after { Thread.current[:time_zone] = nil }
after { Time.zone = nil }

it 'allows {de,}serializing Time' do
time = Time.now
Expand Down