que-rb · ZimbiX · Mar 24, 2022 · Feb 24, 2022 · Dec 23, 2021 · Jan 21, 2021
diff --git a/.github/workflows/tests.yml b/.github/workflows/tests.yml
@@ -7,11 +7,19 @@ jobs:
     runs-on: ubuntu-latest
     strategy:
       matrix:
-        ruby_version: [2.5.x, 2.6.x, 2.7.x]
-        gemfile: ["4.2", "5.2", "6.0"]
-        postgres_version: [9, 10, 11, 12]
-        exclude:
-          - { gemfile: "4.2", ruby_version: "2.7.x" }
+        ruby_version: ['2.7', '3.0', '3.1']
+        rails_gemfile: ['6.0', '6.1']
+        postgres_version: ['14']
+        include:
+        # Postgres versions
+        - { ruby_version: '3.1', rails_gemfile: '6.1', postgres_version: '9' }
+        - { ruby_version: '3.1', rails_gemfile: '6.1', postgres_version: '10' }
+        - { ruby_version: '3.1', rails_gemfile: '6.1', postgres_version: '11' }
+        - { ruby_version: '3.1', rails_gemfile: '6.1', postgres_version: '12' }
+        - { ruby_version: '3.1', rails_gemfile: '6.1', postgres_version: '13' }
+        - { ruby_version: '3.1', rails_gemfile: '6.1', postgres_version: '14' }
+        exclude: []
+    name: "Test: Ruby ${{ matrix.ruby_version }}, Rails ${{ matrix.rails_gemfile }}, PostgreSQL ${{ matrix.postgres_version }}"
     services:
       db:
         image: postgres:${{ matrix.postgres_version }}
@@ -24,16 +32,16 @@ jobs:
           --health-timeout 5s
           --health-retries 5
     steps:
-    - uses: actions/checkout@v1
+    - uses: actions/checkout@v2
     - name: Set up Ruby
-      uses: actions/setup-ruby@v1
+      uses: ruby/setup-ruby@v1
       with:
         ruby-version: ${{ matrix.ruby_version }}
     - name: Test with Rake
       env:
         PGHOST: 127.0.0.1
         PGUSER: postgres
-        BUNDLE_GEMFILE: spec/gemfiles/Gemfile.${{ matrix.gemfile }}
+        BUNDLE_GEMFILE: spec/gemfiles/Gemfile-rails-${{ matrix.rails_gemfile }}
       run: |
         sudo apt-get -yqq install libpq-dev postgresql-client
         createdb que-test

diff --git a/.ruby-version b/.ruby-version
@@ -0,0 +1 @@
+3.1.1
diff --git a/CHANGELOG.md b/CHANGELOG.md
@@ -2,6 +2,7 @@
 
 <!-- MarkdownTOC autolink=true -->
 
+- [2.0.0.beta1](#200beta1)
 - [1.4.0 \(2022-03-23\)](#140-2022-03-23)
 - [1.3.1 \(2022-02-25\)](#131-2022-02-25)
 - [1.3.0 \(2022-02-25\)](#130-2022-02-25)
@@ -51,6 +52,59 @@
 
 <!-- /MarkdownTOC -->
 
+## 2.0.0.beta1
+
+**Preliminary release of Ruby 3 support**
+
+**Notable changes**:
+
+* Support for Ruby 3 introduced
+* Database schema has changed to split the job arguments `args` column into `args` and `kwargs` columns, for reliable args and kwargs splitting for Ruby 3.
+    - The job schema version is now 2. Note that job schema version is distinct from database schema version and Que version. The `job_schema_version` column of the `que_jobs` table no longer defaults and has a not null constraint, so when manually inserting jobs into the table, this must be specified as `2`. If you have a gem that needs to support multiple Que versions, best not to blindly use the value of `Que.job_schema_version`; instead have different code paths depending on the value of `Que.job_schema_version`. You could also use this to know whether keyword arguments are in `args` or `kwargs`.
+* Passing a hash literal as the last job argument to be splatted into job keyword arguments is no longer supported.
+* Dropped support for providing job options as top-level keyword arguments to `Job.enqueue`, i.e. `queue`, `priority`, `run_at`, `job_class`, and `tags`. Job options now need to be nested under the `job_options` keyword argument instead. See [#336](https://github.com/que-rb/que/pull/336)
+* Dropped support for Ruby < 2.7
+* Dropped support for Rails < 6.0
+* The `#by_args` method on the Job model (for both Sequel and ActiveRecord) now searches based on both args and kwargs, but it performs a subset match instead of an exact match. For instance, if your job was scheduled with `'a', 'b', 'c', foo: 'bar', baz: 1`, `by_args('a', 'b', baz: 1)` would find and return the job.
+* This release contains a database migration. You will need to migrate Que to the latest database schema version (6). For example, on ActiveRecord and Rails 6:
+
+```ruby
+class UpdateQueTablesToVersion6 < ActiveRecord::Migration[6.0]
+  def up
+    Que.migrate!(version: 6)
+  end
+
+  def down
+    Que.migrate!(version: 5)
+  end
+end
+```
+
+**Recommended upgrade process**:
+
+When using Que 2.x, a job enqueued with Ruby 2.7 will run as expected on Ruby 3. We recommend:
+
+1. Upgrade your project to the latest 1.x version of Que (1.3.1+)
+    - IMPORTANT: adds support for zero downtime upgrade to Que 2.x, see changelog below
+2. Upgrade your project to Ruby 2.7 and Rails 6.x if it is not already
+3. Upgrade your project to Que 2.x but stay on Ruby 2.7
+    - IMPORTANT: You will need to continue to run Que 1.x workers until all jobs enqueued using Que 1.x (i.e. with a `job_schema_version` of `1`) have been finished. See below
+4. Upgrade your project to Ruby 3
+
+*NOTES:*
+
+* If you were already running Ruby 2.7 and were not passing a hash literal as the last job argument, you *may* be able to upgrade a running system without draining the queue, though this is not recommended.
+* For all other cases, you will need to follow the recommended process above or first completely drain the queue (stop enqueuing new jobs and finish processing any jobs in the database, including cleaning out any expired jobs) before upgrading.
+
+**Deploying Que 1.x and 2.x workers simultaneously**:
+
+To run workers with two different versions of Que, you'll probably need to temporarily duplicate your gem bundle, with the Que version being the only difference. e.g.:
+
+- Copy your `Gemfile` and `Gemfile.lock` into a directory called `que-1-gemfile`
+- Set a suitable Que version in each `Gemfile`
+- Update the bundle at `que-1-gemfile/Gemfile.lock` using `BUNDLE_GEMFILE=que-1-gemfile/Gemfile bundle`
+- Create a second deployment of Que, but with your `que` command prefixed with `BUNDLE_GEMFILE=que-1-gemfile/Gemfile`
+
 ## 1.4.0 (2022-03-23)
 
 - **Fixed**
@@ -61,7 +115,7 @@
         * It became used in 1.0.0.beta4, and that changelog entry has been updated to reflect this.
 - **Documentation**:
     + Reformatted the changelog to be more consistent, including adding links to all issue/PR numbers. [#347](https://github.com/que-rb/que/pull/347)
-
+    + 
 ## 1.3.1 (2022-02-25)
 
 Unfortunately, v1.3.0 was broken. Follow its upgrade instructions, but use this version instead.

diff --git a/Dockerfile b/Dockerfile
@@ -1,4 +1,4 @@
-FROM ruby:2.7.5-slim-buster@sha256:4cbbe2fba099026b243200aa8663f56476950cc64ccd91d7aaccddca31e445b5 AS base
+FROM ruby:3.1.1-slim-buster@sha256:2ada3e4fe7b1703c9333ad4eb9fc12c1d4d60bce0f981281b2151057e928d9ad AS base
 
 # Install libpq-dev in our base layer, as it's needed in all environments
 RUN apt-get update \

diff --git a/Gemfile b/Gemfile
@@ -27,9 +27,4 @@ group :test do
   gem 'pg_examiner', '~> 0.5.2'
 end
 
-platforms :rbx do
-  gem 'rubysl', '~> 2.0'
-  gem 'json', '~> 1.8'
-end
-
 gemspec
diff --git a/README.md b/README.md
@@ -1,6 +1,6 @@
 # Que ![tests](https://github.com/que-rb/que/workflows/tests/badge.svg)
 
-**This README and the rest of the docs on the master branch all refer to Que 1.0. If you're using version 0.x, please refer to the docs on [the 0.x branch](https://github.com/que-rb/que/tree/0.x).**
+**This README and the rest of the docs on the master branch all refer to Que 2.x. For older versions, please refer to the docs on the respective branches: [1.x](https://github.com/que-rb/que/tree/1.x), or [0.x](https://github.com/que-rb/que/tree/0.x).**
 
 *TL;DR: Que is a high-performance job queue that improves the reliability of your application by protecting your jobs with the same [ACID guarantees](https://en.wikipedia.org/wiki/ACID) as the rest of your data.*
 
@@ -23,9 +23,9 @@ Que's secondary goal is performance. The worker process is multithreaded, so tha
 
 Compatibility:
 
-- MRI Ruby 2.2+
+- MRI Ruby 2.7+
 - PostgreSQL 9.5+
-- Rails 4.1+ (optional)
+- Rails 6.0+ (optional)
 
 **Please note** - Que's job table undergoes a lot of churn when it is under high load, and like any heavily-written table, is susceptible to bloat and slowness if Postgres isn't able to clean it up. The most common cause of this is long-running transactions, so it's recommended to try to keep all transactions against the database housing Que's job table as short as possible. This is good advice to remember for any high-activity database, but bears emphasizing when using tables that undergo a lot of writes.
 
@@ -54,12 +54,12 @@ gem install que
 First, create the queue schema in a migration. For example:
 
 ```ruby
-class CreateQueSchema < ActiveRecord::Migration[5.0]
+class CreateQueSchema < ActiveRecord::Migration[6.0]
   def up
     # Whenever you use Que in a migration, always specify the version you're
     # migrating to. If you're unsure what the current version is, check the
     # changelog.
-    Que.migrate!(version: 5)
+    Que.migrate!(version: 6)
   end
 
   def down
@@ -117,10 +117,10 @@ end
 You can also add options to run the job after a specific time, or with a specific priority:
 
 ```ruby
-ChargeCreditCard.enqueue card.id, user_id: current_user.id, run_at: 1.day.from_now, priority: 5
+ChargeCreditCard.enqueue(card.id, user_id: current_user.id, job_options: { run_at: 1.day.from_now, priority: 5 })
 ```
 ## Running the Que Worker
-In order to process jobs, you must start a separate worker process outside of your main server. 
+In order to process jobs, you must start a separate worker process outside of your main server.
 
 ```bash
 bundle exec que
@@ -142,7 +142,7 @@ You may need to pass que a file path to require so that it can load your app. Qu
 
 If you're using ActiveRecord to dump your database's schema, please [set your schema_format to :sql](http://guides.rubyonrails.org/migrations.html#types-of-schema-dumps) so that Que's table structure is managed correctly. This is a good idea regardless, as the `:ruby` schema format doesn't support many of PostgreSQL's advanced features.
 
-Pre-1.0, the default queue name needed to be configured in order for Que to work out of the box with Rails. In 1.0 the default queue name is now 'default', as Rails expects, but when Rails enqueues some types of jobs it may try to use another queue name that isn't worked by default. You can either:
+Pre-1.0, the default queue name needed to be configured in order for Que to work out of the box with Rails. As of 1.0 the default queue name is now 'default', as Rails expects, but when Rails enqueues some types of jobs it may try to use another queue name that isn't worked by default. You can either:
 
 - [Configure Rails](https://guides.rubyonrails.org/configuring.html) to send all internal job types to the 'default' queue by adding the following to `config/application.rb`:
 

diff --git a/bin/command_line_interface.rb b/bin/command_line_interface.rb
@@ -220,7 +220,7 @@ def parse(
 
         locker =
           begin
-            Que::Locker.new(options)
+            Que::Locker.new(**options)
           rescue => e
             output.puts(e.message)
             return 1

diff --git a/bin/command_line_interface.spec.rb b/bin/command_line_interface.spec.rb
@@ -43,7 +43,7 @@ def assert_successful_invocation(
     default_require_file: Que::CommandLineInterface::RAILS_ENVIRONMENT_FILE
   )
 
-    BlockJob.enqueue(queue: queue_name, priority: 1)
+    BlockJob.enqueue(job_options: { queue: queue_name, priority: 1 })
 
     thread =
       Thread.new do

diff --git a/docker-compose.yml b/docker-compose.yml
@@ -10,13 +10,14 @@ services:
       - db
     volumes:
       - .:/work
-      - ruby-2.7.5-gem-cache:/usr/local/bundle
+      - ruby-3.1.1-gem-cache:/usr/local/bundle
       - ~/.docker-rc.d/:/.docker-rc.d/:ro
     working_dir: /work
     entrypoint: /work/scripts/docker-entrypoint
     command: bash
     environment:
       DATABASE_URL: postgres://que:que@db/que-test
+      USE_RAILS: ~
 
   db:
     image: "postgres:${POSTGRES_VERSION-13}"
@@ -43,4 +44,4 @@ services:
 
 volumes:
   db-data: ~
-  ruby-2.7.5-gem-cache: ~
+  ruby-3.1.1-gem-cache: ~
diff --git a/docs/README.md b/docs/README.md
@@ -128,8 +128,8 @@ There are other docs to read if you're using [Sequel](#using-sequel) or [plain P
 After you've connected Que to the database, you can manage the jobs table. You'll want to migrate to a specific version in a migration file, to ensure that they work the same way even when you upgrade Que in the future:
 
 ```ruby
-# Update the schema to version #5.
-Que.migrate!(version: 5)
+# Update the schema to version #6.
+Que.migrate!(version: 6)
 
 # Remove Que's jobs table entirely.
 Que.migrate!(version: 0)
@@ -441,7 +441,7 @@ que -q default -q credit_cards
 Then you can set jobs to be enqueued in that queue specifically:
 
 ```ruby
-ProcessCreditCard.enqueue current_user.id, queue: 'credit_cards'
+ProcessCreditCard.enqueue(current_user.id, job_options: { queue: 'credit_cards' })
 
 # Or:
 
@@ -455,7 +455,7 @@ end
 In some cases, the ProcessCreditCard class may not be defined in the application that is enqueueing the job. In that case, you can specify the job class as a string:
 
 ```ruby
-Que.enqueue current_user.id, job_class: 'ProcessCreditCard', queue: 'credit_cards'
+Que.enqueue(current_user.id, job_options: { job_class: 'ProcessCreditCard', queue: 'credit_cards' })
 ```
 
 ## Shutting Down Safely
@@ -549,7 +549,7 @@ require 'que'
 Sequel.migration do
   up do
     Que.connection = self
-    Que.migrate!(version: 5)
+    Que.migrate!(version: 6)
   end
   down do
     Que.connection = self
@@ -585,7 +585,7 @@ Sequel automatically wraps model persistance actions (create, update, destroy) i
 
 ## Using Que With ActiveJob
 
-You can include `Que::ActiveJob::JobExtensions` into your `ApplicationJob` subclass to get support for all of Que's 
+You can include `Que::ActiveJob::JobExtensions` into your `ApplicationJob` subclass to get support for all of Que's
 [helper methods](#job-helper-methods). These methods will become no-ops if you use a queue adapter that isn't Que, so if you like to use a different adapter in development they shouldn't interfere.
 
 Additionally, including `Que::ActiveJob::JobExtensions` lets you define a run() method that supports keyword arguments.

diff --git a/lib/que.rb b/lib/que.rb
@@ -29,6 +29,7 @@ def SQL.[]=(k,v); super(k, v.strip.gsub(/\s+/, ' ').freeze); end
   require_relative 'que/utils/logging'
   require_relative 'que/utils/middleware'
   require_relative 'que/utils/queue_management'
+  require_relative 'que/utils/ruby2_keywords'
   require_relative 'que/utils/transactions'
 
   require_relative 'que/version'
@@ -61,6 +62,7 @@ class << self
     include Utils::Logging
     include Utils::Middleware
     include Utils::QueueManagement
+    include Utils::Ruby2Keywords
     include Utils::Transactions
 
     extend Forwardable