Skip to content

Commit

Permalink
Remove deprecation silencers for v3.99 release
Browse files Browse the repository at this point in the history
  • Loading branch information
bensheldon committed Jul 7, 2024
1 parent e7c89be commit 4d241a7
Show file tree
Hide file tree
Showing 3 changed files with 5 additions and 8 deletions.
6 changes: 2 additions & 4 deletions README.md
Original file line number Diff line number Diff line change
Expand Up @@ -878,17 +878,15 @@ To perform upgrades to the GoodJob database tables:

GoodJob v4 changes how job and job execution records are stored in the database; moving from job and executions being commingled in the `good_jobs` table to separately and discretely storing job executions in `good_job_executions`. To safely upgrade, all unfinished jobs must use the new format. This change was introduced in GoodJob [v3.15.4 (April 2023)](https://github.com/bensheldon/good_job/releases/tag/v3.15.4), so your application is likely ready-to-upgrade already if you have kept up with GoodJob updates.

**⚠️GoodJob v4.0.0 and v3.99 have not yet been released, though you can still prepare for the upgrade.**

To upgrade:

1. ~~Upgrade to v3.99.x, following the minor version upgrade process, running any remaining database migrations (rails g good_job:update) and addressing deprecation warnings.~~ (Not yet released)
1. Upgrade to v3.99.x, following the minor version upgrade process, running any remaining database migrations (rails g good_job:update) and addressing deprecation warnings.
1. Check if your application is safe to upgrade to the new job record format by running either:
- In a production console, run `GoodJob.v4_ready?` which should return `true` when safely upgradable.
- Or, when connected to the production database verify that `SELECT COUNT(*) FROM "good_jobs" WHERE finished_at IS NULL AND is_discrete IS NOT TRUE` returns `0`

If not all unfinished jobs are stored in the new format, either wait to upgrade until those jobs finish or discard them. Not waiting could prevent those jobs from successfully running when upgrading to v4.
1. ~~Upgrade from v3.99.x to v4.x~~ (Not yet released)
1. Upgrade from v3.99.x to v4.x.

Notable changes:

Expand Down
3 changes: 1 addition & 2 deletions app/models/good_job/base_execution.rb
Original file line number Diff line number Diff line change
Expand Up @@ -310,11 +310,10 @@ def self.build_for_enqueue(active_job, overrides = {})

# Construct arguments for GoodJob::Execution from an ActiveJob instance.
def self.enqueue_args(active_job, overrides = {})
if active_job.priority && GoodJob.configuration.smaller_number_is_higher_priority.nil?
if active_job.priority && GoodJob.configuration.smaller_number_is_higher_priority.in?([nil, false])
GoodJob.deprecator.warn(<<~DEPRECATION)
The next major version of GoodJob (v4.0) will change job `priority` to give smaller numbers higher priority (default: `0`), in accordance with Active Job's definition of priority.
To opt-in to this behavior now, set `config.good_job.smaller_number_is_higher_priority = true` in your GoodJob initializer or application.rb.
To not opt-in yet, but silence this deprecation warning, set `config.good_job.smaller_number_is_higher_priority = false`.
DEPRECATION
end

Expand Down
4 changes: 2 additions & 2 deletions spec/app/models/good_job/execution_spec.rb
Original file line number Diff line number Diff line change
Expand Up @@ -143,10 +143,10 @@ def perform(result_value = nil, raise_error: false)
context 'when smaller_number_higher_priority=false' do
before { allow(Rails.application.config).to receive(:good_job).and_return(smaller_number_is_higher_priority: false) }

it 'does not warn' do
it 'warns to ensure the upgrade is obvious' do
active_job.priority = 50
described_class.enqueue(active_job)
expect(GoodJob.deprecator).not_to have_received(:warn)
expect(GoodJob.deprecator).to have_received(:warn)
end
end
end
Expand Down

0 comments on commit 4d241a7

Please sign in to comment.