All Versions
51
Latest Version
Avg Release Cycle
105 days
Latest Release
878 days ago

Changelog History
Page 1

  • v2.2.0 Changes

    August 29, 2022
    • 🔄 Changed:
      • When migrating, now raises an exception when the Que DB schema version is missing from the database. The migrations system records this version in a comment on the que_jobs table. #379
        • > Que::Error: Cannot determine Que DB schema version. > > The que_jobs table is missing its comment recording the Que DB schema version. This is likely due to a bug in Rails schema dump in Rails 7 versions prior to 7.0.3, omitting comments - see https://github.com/que-rb/que/issues/363. Please determine the appropriate schema version from your migrations and record it manually by running the following SQL (replacing version as appropriate): > > COMMENT ON TABLE que_jobs IS 'version';
    • ✂ Removed:
      • Removed support for upgrading directly from a version of Que prior to v0.5.0 (released on 2014-01-14), which introduced the migrations system. It's too difficult to handle the different DB schemas from prior to this.
    • Internal:
      • Moved command_line_interface.rb from bin/ to lib/. #378

  • v2.1.0 Changes

    August 25, 2022
    • ➕ Added:
      • Added bulk enqueue interface for performance when enqueuing a large number of jobs at once - [docs](docs#enqueueing-jobs-in-bulk).
    • 🗄 Deprecated:
      • Deprecated que_state_notify trigger (que_state notification channel / job_change notification message). See #372. We plan to remove this in a future release - let us know on the issue if you desire otherwise.

    🚀 This release contains a database migration. You will need to migrate Que to the latest database schema version (7). For example, on ActiveRecord and Rails 6:

    class UpdateQueTablesToVersion7 < ActiveRecord::Migration[6.0]
  def up
    Que.migrate!(version: 7)
  end

  def down
    Que.migrate!(version: 6)
  end
end

  • v2.0.0 Changes

    August 25, 2022

    ⬆️ Important: Do not upgrade straight to Que 2. You will need to first update to the latest 1.x version, apply the Que database schema migration, and deploy, before you can safely begin the process of upgrading to Que 2. See the 2.0.0.beta1 changelog entry for details.

    👀 See beta 2.0.0.beta1, plus:

    • 🛠 Fixed:
      • Updated to use non-deprecated method from PG when params are passed (#async_exec_params). #374

    🚀 Note that @dtcristo submitted a PR proposing an easier upgrade path to Que 2 and Ruby 3 - #365. We are yet to properly consider this, but a later release which includes this feature would mean you don't need to simultaneously deploy Que 1.x and 2.x workers during the upgrade.

  • v2.0.0.beta1 Changes

    March 24, 2022

    🚀 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
    • ⬇️ 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:
    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

    ⬆️ We'd appreciate feedback on your experience upgrading to and running Que 2. Feel free to post on our Discord, or if you run into trouble, open an issue on GitHub.

  • v1.4.1 Changes

    July 24, 2022
    • ➕ Added
      • Added Ruby version requirement of < 3. For Ruby 3 compatibility, upgrade to Que 2 - upgrade process

  • v1.4.0 Changes

    March 23, 2022
    • 🛠 Fixed
      • The poller will no longer sleep when jobs exist for only some of its priorities. It now skips sleeping when a poll returns more jobs than the lowest priority requested. #349.
        • An alternative was considered which skipped polling when only some of the waiting worker priorities would be fully utilised (diagram explanation); but this was decided against for code complexity reasons. #348
    • 🗄 Deprecated:
      • Deprecated --minimum-buffer-size option. It was not actually used, and will be removed in v2.0.0. #346
        • 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

  • v1.3.1 Changes

    February 25, 2022

    ⬆️ Unfortunately, v1.3.0 was broken. Follow its upgrade instructions, but use this version instead.

    • 🛠 Fixed
      • Fixed startup error: undefined method 'job_schema_version' for Que:Module, in #343

  • v1.3.0 Changes

    February 25, 2022

    ACTION REQUIRED

    🚀 This release will allow you to safely upgrade to Que 2 when it comes out, without first needing to empty your que_jobs table.

    🚀 You will need to first update to this version, apply the Que schema migration, and deploy, before you can safely begin the process of upgrading to Que 2.

    👷 Que 2 will bring Ruby 3 support, but to do that, the job arguments in the que_jobs table will need to be split into two columns - repurposing the existing one for positional arguments only (args), and adding a new one for keyword arguments (kwargs). This is so that Que running in Ruby 3, when reading job arguments stored in the database, can disambiguate between keyword arguments and a last positional argument hash.

    ⬆️ The args split hasn't happened yet, but when it does, we still need to be able to successfully process all the existing queued jobs which have their keyword arguments in the args column still. Our solution is for you to have both Que 1 workers and Que 2 workers operating simultaneously during the upgrade, each processing only the jobs enqueued from that version. Once all the Que 1 jobs are processed, the Que 1 workers can be retired.

    👷 To allow the different worker versions to tell which jobs belong to which, we've added a new column to the que_jobs table in this version, job_schema_version. Jobs enqueued with Que 1 will have a 1 here, and jobs from Que 2 will have a 2. Que schema migration 5 will default the job schema version of all existing jobs to 1.

    ✅ You will need to migrate Que to the latest Que schema version (5). For instance, on ActiveRecord and Rails 6:

    class UpdateQueTablesToVersion5 < ActiveRecord::Migration[6.0]
  def up
    Que.migrate!(version: 5)
  end
  def down
    Que.migrate!(version: 4)
  end
end

    🚀 You must apply the schema migration and deploy to upgrade all workers.

    🚀 No further action is required from you at this stage. The Que 2 release changelog will provide full upgrade instructions for the process briefly described above of simultaneously running both Que 1 & 2 workers. Note that you won't be required to upgrade from Ruby 2.7 to Ruby 3 at the same time as upgrading to Que 2.

    ⚡️ If you use any Que plugins or custom code that interacts with the que_jobs table, before you can upgrade to Que 2, you will need to make sure they are updated for compatibility with Que 2: They'll need to make use of the kwargs column, and when inserting jobs, put a 2 into the job_schema_version column rather than continue to rely on its soon-to-be-removed default of 1.

    Other improvements:

    • 🔋 Features:
      • Log config on startup, in #337
    • Internal:
      • Added Git pre-push hook, in #338
      • Documented our gem release process, in #341

  • v1.2.0 Changes

    February 23, 2022
    • 🗄 Deprecated
      • Providing job options as top level keyword arguments to Job.enqueue is now deprecated. Support will be dropped in 2.0. Job options should be nested under the job_options keyword arg instead. See #336

  • v1.1.0 Changes

    February 21, 2022
    • 🔋 Features:
    • Internal:
      • Add Dockerised development environment, in #324