cloudtasker 0.10.rc5 → 0.10.1

checksums.yaml

@@ -1,7 +1,7 @@
 ---
 SHA256:
-  metadata.gz: db7ce2488df7c451c0ed08a2674c32e6e5964a926ad8bf158fee3e76ec71ee82
-  data.tar.gz: 354177692074ddf3aa74fb1dba70dd56933211b460f035884fbf34bc87dc89fc
+  metadata.gz: c0f76715e1b778b035aba4e5bd6175b7d632bb114dcaa471f79e6be29013933e
+  data.tar.gz: 8d059110a3e90b04375410b7030d4773ea34d2cc8da0ac89cad20ba146939080
 SHA512:
-  metadata.gz: 627dc29f6318bc4f0f676deea5ea932f6ec6414cf7f98c3f986132de59c44d30db5d645c518a04bf98ca99925719efce7a430a48a85d83be1cd90551a5f8206a
-  data.tar.gz: e9806327d16e5ac6700577732cc9347f403eb21c6debd52cbacb36157af110a3ccab917e01fab9d6cd87d98ae0cfa1558fe7ebf0d1a938d4a0b40a13a492e87d
+  metadata.gz: b6e33bd5cd5587baf20336445833938fcc01e12fa6f43f0236bcb90cf4f8fb8463545f89bca85f3511d95db8b0c05d4bcfe83f94b9a7da3ec2dca51f5f64e660
+  data.tar.gz: 7ac3e128edfd635b543160391b38bcb7acc840aa306cc6713e7f9aa5cd76ea01da3616d293f7f9222496449419392ac2d644bcd643315cd75661a93b1577ac0f

data/.github/workflows/test.yml

@@ -2,9 +2,9 @@ name: Test
 
 on:
   push:
-    branches: [ master ]
+    branches: [ master, 0.9-stable ]
   pull_request:
-    branches: [ master ]
+    branches: [ master, 0.9-stable ]
 
 jobs:
   build:
@@ -21,6 +21,10 @@ jobs:
           - 'google-cloud-tasks-1.3'
           - 'rails-5.2'
           - 'rails-6.0'
+          - 'semantic_logger-3.4'
+          - 'semantic_logger-4.6'
+          - 'semantic_logger-4.7.0'
+          - 'semantic_logger-4.7.2'
     steps:
       - name: Setup System
         run: sudo apt-get install libsqlite3-dev
@@ -38,4 +42,4 @@ jobs:
           bundle install --jobs 4 --retry 3
           bundle exec rubocop
           bundle exec appraisal ${APPRAISAL_CONTEXT} bundle
-          bundle exec appraisal ${APPRAISAL_CONTEXT} rspec
+          bundle exec appraisal ${APPRAISAL_CONTEXT} rspec

data/.rubocop.yml

@@ -37,4 +37,10 @@ Metrics/BlockLength:
 Style/Documentation:
   Exclude:
     - 'examples/**/*'
-    - 'spec/**/*'
+    - 'spec/**/*'
+
+Metrics/ParameterLists:
+  CountKeywordArgs: false
+
+RSpec/MessageSpies:
+  Enabled: false

data/Appraisals

@@ -23,3 +23,19 @@ end
 appraise 'rails-6.0' do
   gem 'rails', '6.0'
 end
+
+appraise 'semantic_logger-3.4' do
+  gem 'semantic_logger', '3.4.1'
+end
+
+appraise 'semantic_logger-4.6' do
+  gem 'semantic_logger', '4.6.1'
+end
+
+appraise 'semantic_logger-4.7.0' do
+  gem 'semantic_logger', '4.7.0'
+end
+
+appraise 'semantic_logger-4.7.2' do
+  gem 'semantic_logger', '4.7.2'
+end

data/CHANGELOG.md

@@ -1,5 +1,37 @@
 # Changelog
 
+## [v0.10.1](https://github.com/keypup-io/cloudtasker/tree/v0.10.1) (2020-10-05)
+
+[Full Changelog](https://github.com/keypup-io/cloudtasker/compare/v0.10.0...v0.10.1)
+
+**Fixed bugs:**
+- Logging: fix log processing with `semantic_logger` `v4.7.2`. Accept any args on block passed to the logger.
+
+## [v0.10.0](https://github.com/keypup-io/cloudtasker/tree/v0.10.0) (2020-09-02)
+
+[Full Changelog](https://github.com/keypup-io/cloudtasker/compare/v0.9.3...v0.10.0)
+
+**Improvements:**
+- Logging: Add worker name in log messages
+- Logging: Add job duration in log messages
+- Logging: Add Cloud Cloud Task ID in log messages
+- Unique Job: Support TTL for lock keys. This feature prevents queues from being dead-locked when a critical crash occurs while processing a unique job.
+- Worker: support payload storage in Redis instead of sending the payload to Google Cloud Tasks. This is useful when job arguments are expected to exceed 100kb, which is the limit set by Google Cloud Tasks
+
+**Fixed bugs:**
+- Local processing error: improve error handling and retries around network interruptions
+- Redis client: prevent deadlocks in high concurrency scenario by slowing down poll time and enforcing lock expiration
+- Redis client: use connecion pool with Redis to prevent race conditions
+- Google API: improve error handling on job creation
+- Google API: use the `X-CloudTasks-TaskRetryCount` instead of `X-CloudTasks-TaskExecutionCount` to detect how many retries Google Cloud Tasks has performed. Using `X-CloudTasks-TaskRetryCount` is theoretically less accurate than using `X-CloudTasks-TaskExecutionCount` because it includes the number of "app unreachable" retries but `X-CloudTasks-TaskExecutionCount` is currently bugged and remains at zero all the time. See [this issue](https://github.com/keypup-io/cloudtasker/issues/6)
+
+## [v0.9.3](https://github.com/keypup-io/cloudtasker/tree/v0.9.3) (2020-06-25)
+
+[Full Changelog](https://github.com/keypup-io/cloudtasker/compare/v0.9.2...v0.9.3)
+
+**Fixed bugs:**
+- Google Cloud Tasks: lock version to `~> 1.0` (Google recently released a v2 which changes its bindings completely). An [issue](https://github.com/keypup-io/cloudtasker/issues/11) has been raised to upgrade Cloudtasker to `google-cloud-tasks` `v2`.
+
 ## [v0.9.2](https://github.com/keypup-io/cloudtasker/tree/v0.9.2) (2020-03-04)
 
 [Full Changelog](https://github.com/keypup-io/cloudtasker/compare/v0.9.1...v0.9.2)
@@ -71,7 +103,3 @@ For Sinatra applications please update your Cloudtasker controller according to
 ## [v0.1.0](https://github.com/keypup-io/cloudtasker/tree/v0.1.0) (2019-11-17)
 
 [Full Changelog](https://github.com/keypup-io/cloudtasker/compare/c137feb1ceaaaa4e2fecac0d1f0b4c73151ae002...v0.1.0)
-
-
-
-\* *This Changelog was automatically generated by [github_changelog_generator](https://github.com/github-changelog-generator/github-changelog-generator)*

data/README.md

@@ -6,11 +6,11 @@ Background jobs for Ruby using Google Cloud Tasks.
 
 Cloudtasker provides an easy to manage interface to Google Cloud Tasks for background job processing. Workers can be defined programmatically using the Cloudtasker DSL and enqueued for processing using a simple to use API.
 
-Cloudtasker is particularly suited for serverless applications only responding to HTTP requests and where running a dedicated job processing is not an option (e.g. deploy via [Cloud Run](https://cloud.google.com/run)). All jobs enqueued in Cloud Tasks via Cloudtasker eventually get processed by your application via HTTP requests.
+Cloudtasker is particularly suited for serverless applications only responding to HTTP requests and where running a dedicated job processing server is not an option (e.g. deploy via [Cloud Run](https://cloud.google.com/run)). All jobs enqueued in Cloud Tasks via Cloudtasker eventually get processed by your application via HTTP requests.
 
 Cloudtasker also provides optional modules for running [cron jobs](docs/CRON_JOBS.md), [batch jobs](docs/BATCH_JOBS.md) and [unique jobs](docs/UNIQUE_JOBS.md).
 
-A local processing server is also available in development. This local server processes jobs in lieu of Cloud Tasks and allows you to work offline.
+A local processing server is also available for development. This local server processes jobs in lieu of Cloud Tasks and allows you to work offline.
 
 ## Summary
 
@@ -34,7 +34,11 @@ A local processing server is also available in development. This local server pr
     1. [HTTP Error codes](#http-error-codes)
     2. [Error callbacks](#error-callbacks)
     3. [Max retries](#max-retries)
-10. [Best practices building workers](#best-practices-building-workers)
+10. [Testing](#testing)
+    1. [Test helper setup](#test-helper-setup)
+    2. [In-memory queues](#in-memory-queues)
+    3. [Unit tests](#unit-tests)
+11. [Best practices building workers](#best-practices-building-workers)
 
 ## Installation
 
@@ -48,7 +52,7 @@ And then execute:
 
     $ bundle
 
-Or install it yourself as:
+Or install it yourself with:
 
     $ gem install cloudtasker
 
@@ -71,7 +75,7 @@ Cloudtasker.configure do |config|
   # Adapt the server port to be the one used by your Rails web process
   #
   config.processor_host = 'http://localhost:3000'
-  
+
   #
   # If you do not have any Rails secret_key_base defined, uncomment the following
   # This secret is used to authenticate jobs sent to the processing endpoint
@@ -154,14 +158,14 @@ The gem can be configured through an initializer. See below all the available co
 Cloudtasker.configure do |config|
   #
   # If you do not have any Rails secret_key_base defined, uncomment the following.
-  # This secret is used to authenticate jobs sent to the processing endpoint 
+  # This secret is used to authenticate jobs sent to the processing endpoint
   # of your application.
   #
   # Default with Rails: Rails.application.credentials.secret_key_base
   #
   # config.secret = 'some-long-token'
 
-  # 
+  #
   # Specify the details of your Google Cloud Task location.
   #
   # This not required in development using the Cloudtasker local server.
@@ -185,21 +189,21 @@ Cloudtasker.configure do |config|
   #
   # Specific queues can be created in Cloud Tasks using the gcloud SDK or
   # via the `rake cloudtasker:setup_queue name=<queue_name>` task.
-  # 
+  #
   config.gcp_queue_prefix = 'my-app'
 
-  # 
+  #
   # Specify the publicly accessible host for your application
   #
   # > E.g. in development, using the cloudtasker local server
   # config.processor_host = 'http://localhost:3000'
-  # 
+  #
   # > E.g. in development, using `config.mode = :production` and ngrok
   # config.processor_host = 'https://111111.ngrok.io'
   #
   config.processor_host = 'https://app.mydomain.com'
 
-  # 
+  #
   # Specify the mode of operation:
   # - :development => jobs will be pushed to Redis and picked up by the Cloudtasker local server
   # - :production => jobs will be pushed to Google Cloud Tasks. Requires a publicly accessible domain.
@@ -208,20 +212,20 @@ Cloudtasker.configure do |config|
   #
   # config.mode = Rails.env.production? || Rails.env.my_other_env? ? :production : :development
 
-  # 
+  #
   # Specify the logger to use
-  # 
+  #
   # Default with Rails: Rails.logger
   # Default without Rails: Logger.new(STDOUT)
-  # 
+  #
   # config.logger = MyLogger.new(STDOUT)
 
-  # 
+  #
   # Specify how many retries are allowed on jobs. This number of retries excludes any
-  # connectivity error that would be due to the application being down or unreachable.
-  # 
+  # connectivity error due to the application being down or unreachable.
+  #
   # Default: 25
-  # 
+  #
   # config.max_retries = 10
 
   #
@@ -246,7 +250,7 @@ Cloudtasker.configure do |config|
   # You can set this configuration parameter to a KB value if you want to store jobs
   # args in redis only if the JSONified arguments payload exceeds that threshold.
   #
-  # Supported since: v0.10.rc1
+  # Supported since: v0.10.0
   #
   # Default: false
   #
@@ -258,7 +262,7 @@ Cloudtasker.configure do |config|
 end
 ```
 
-If the default queue `<gcp_queue_prefix>-default` does not exist in Cloud Tasks you should [create it using the gcloud sdk](https://cloud.google.com/tasks/docs/creating-queues). 
+If the default queue `<gcp_queue_prefix>-default` does not exist in Cloud Tasks you should [create it using the gcloud sdk](https://cloud.google.com/tasks/docs/creating-queues).
 
 Alternatively with Rails you can simply run the following rake task if you have queue admin permissions (`cloudtasks.queues.get` and `cloudtasks.queues.create`).
 ```bash
@@ -289,7 +293,7 @@ MyWorker.schedule(args: [arg1, arg2], time_at: Time.parse('2025-01-01 00:50:00Z'
 MyWorker.schedule(args: [arg1, arg2], time_in: 5 * 60, queue: 'critical')
 ```
 
-Cloudtasker also provides a helper for re-enqueuing jobs. Re-enqueued jobs keep the same worker id. Some middlewares may rely on this to track the fact that that a job didn't actually complete (e.g. Cloustasker batch). This is optional and you can always fallback to using exception management (raise an error) to retry/re-enqueue jobs.
+Cloudtasker also provides a helper for re-enqueuing jobs. Re-enqueued jobs keep the same job id. Some middlewares may rely on this to track the fact that that a job didn't actually complete (e.g. Cloustasker batch). This is optional and you can always fallback to using exception management (raise an error) to retry/re-enqueue jobs.
 
 E.g.
 ```ruby
@@ -360,7 +364,7 @@ CriticalWorker.schedule(args: [1], queue: :important)
 Cloudtasker comes with three optional features:
 - Cron Jobs [[docs](docs/CRON_JOBS.md)]: Run jobs at fixed intervals.
 - Batch Jobs [[docs](docs/BATCH_JOBS.md)]: Run jobs in jobs and track completion of the overall batch.
-- Unique Jobs [[docs](docs/UNIQUE_JOBS.md)]: Ensure uniqueness of jobs based on job arguments. 
+- Unique Jobs [[docs](docs/UNIQUE_JOBS.md)]: Ensure uniqueness of jobs based on job arguments.
 
 ## Working locally
 
@@ -377,9 +381,9 @@ You can configure your application to use the Cloudtasker local server using the
 
 Cloudtasker.configure do |config|
   # ... other options
-  
+
   # Push jobs to redis and let the Cloudtasker local server collect them
-  # This is the default mode unless CLOUDTASKER_ENV or RAILS_ENV or RACK_ENV is set 
+  # This is the default mode unless CLOUDTASKER_ENV or RAILS_ENV or RACK_ENV is set
   # to a non-development environment
   config.mode = :development
 end
@@ -423,7 +427,7 @@ Cloudtasker.configure do |config|
 
   # Use your ngrok domain as the processor host
   config.processor_host = 'https://your-tunnel-id.ngrok.io'
-  
+
   # Force Cloudtasker to use Google Cloud Tasks in development
   config.mode = :production
 end
@@ -467,14 +471,14 @@ end
 
 Will generate the following log with context `{:worker=> ..., :job_id=> ..., :job_meta=> ...}`
 ```log
-[Cloudtasker][d76040a1-367e-4e3b-854e-e05a74d5f773] Job run with foo. This is working!: {:worker=>"DummyWorker", :job_id=>"d76040a1-367e-4e3b-854e-e05a74d5f773", :job_meta=>{}}
+[Cloudtasker][d76040a1-367e-4e3b-854e-e05a74d5f773] Job run with foo. This is working!: {:worker=>"DummyWorker", :job_id=>"d76040a1-367e-4e3b-854e-e05a74d5f773", :job_meta=>{}, :task_id => "4e755d3f-6de0-426c-b4ac-51edd445c045"}
 ```
 
 The way contextual information is displayed depends on the logger itself. For example with [semantic_logger](http://rocketjob.github.io/semantic_logger) contextual information might not appear in the log message but show up as payload data on the log entry itself (e.g. using the fluentd adapter).
 
 Contextual information can be customised globally and locally using a log context_processor. By default the `Cloudtasker::WorkerLogger` is configured the following way:
 ```ruby
-Cloudtasker::WorkerLogger.log_context_processor = ->(worker) { worker.to_h.slice(:worker, :job_id, :job_meta) }
+Cloudtasker::WorkerLogger.log_context_processor = ->(worker) { worker.to_h.slice(:worker, :job_id, :job_meta, :job_queue, :task_id) }
 ```
 
 You can decide to add a global identifier for your worker logs using the following:
@@ -482,7 +486,7 @@ You can decide to add a global identifier for your worker logs using the followi
 # config/initializers/cloudtasker.rb
 
 Cloudtasker::WorkerLogger.log_context_processor = lambda { |worker|
-  worker.to_h.slice(:worker, :job_id, :job_meta).merge(app: 'my-app')
+  worker.to_h.slice(:worker, :job_id, :job_meta, :job_queue, :task_id).merge(app: 'my-app')
 }
 ```
 
@@ -503,9 +507,24 @@ end
 
 See the [Cloudtasker::Worker class](lib/cloudtasker/worker.rb) for more information on attributes available to be logged in your `log_context_processor` proc.
 
+### Searching logs: Job ID vs Task ID
+**Note**: `task_id` field is available in logs starting with `0.10.0`
+
+Job instances are assigned two different different IDs for tracking and logging purpose: `job_id` and `task_id`. These IDs are found in each log entry to facilitate search.
+
+| Field | Definition |
+|------|-------------|
+| `job_id` | This ID is generated by Cloudtasker. It identifies the job along its entire lifecyle. It is persistent across retries and reschedules. |
+| `task_id` | This ID is generated by Google Cloud Tasks. It identifies a job instance on the Google Cloud Task side. It is persistent across retries but NOT across reschedules. |
+
+The Google Cloud Task UI (GCP console) lists all the tasks pending/retrying and their associated task id (also called "Task name"). From there you can:
+1. Use a task ID to lookup the logs of a specific job instance in Stackdriver Logging (or any other logging solution).
+2. From (1) you can retrieve the `job_id` attribute of the job.
+3. From (2) you can use the `job_id` to lookup the job logs along its entire lifecycle.
+
 ## Error Handling
 
-Jobs failing will automatically return an HTTP error to Cloud Task and trigger a retry at a later time. The number of Cloud Task retries Cloud Task will depend on the configuration of your queue in Cloud Tasks.
+Jobs failures will return an HTTP error to Cloud Task and trigger a retry at a later time. The number of Cloud Task retries depends on the configuration of your queue in Cloud Tasks.
 
 ### HTTP Error codes
 
@@ -513,6 +532,7 @@ Jobs failing will automatically return the following HTTP error code to Cloud Ta
 
 | Code | Description |
 |------|-------------|
+| 204 | The job was processed successfully |
 | 205 | The job is dead and has been removed from the queue |
 | 404 | The job has specified an incorrect worker class.  |
 | 422 | An error happened during the execution of the worker (`perform` method) |
@@ -551,26 +571,24 @@ By default jobs are retried 25 times - using an exponential backoff - before bei
 
 Note that the number of retries set on your Cloud Task queue should be many times higher than the number of retries configured in Cloudtasker because Cloud Task also includes failures to connect to your application. Ideally set the number of retries to `unlimited` in Cloud Tasks.
 
-**Note**: The `X-CloudTasks-TaskExecutionCount` header sent by Google Cloud Tasks and providing the number of retries outside of `HTTP 503` (instance not reachable) is currently bugged and remains at `0` all the time. Starting with `0.10.rc3` Cloudtasker uses the `X-CloudTasks-TaskRetryCount` header to detect the number of retries. This header includes `HTTP 503` errors which means that if your application is down at some point, jobs will fail and these failures will be counted toward the maximum number of retries. A [bug report](https://issuetracker.google.com/issues/154532072) has been raised with GCP to address this issue. Once fixed we will revert to using `X-CloudTasks-TaskExecutionCount` to avoid counting `HTTP 503` as job failures.
+**Note**: The `X-CloudTasks-TaskExecutionCount` header sent by Google Cloud Tasks and providing the number of retries outside of `HTTP 503` (instance not reachable) is currently bugged and remains at `0` all the time. Starting with `v0.10.0` Cloudtasker uses the `X-CloudTasks-TaskRetryCount` header to detect the number of retries. This header includes `HTTP 503` errors which means that if your application is down at some point, jobs will fail and these failures will be counted toward the maximum number of retries. A [bug report](https://issuetracker.google.com/issues/154532072) has been raised with GCP to address this issue. Once fixed we will revert to using `X-CloudTasks-TaskExecutionCount` to avoid counting `HTTP 503` as job failures.
 
 E.g. Set max number of retries globally via the cloudtasker initializer.
 ```ruby
 # config/initializers/cloudtasker.rb
 
 Cloudtasker.configure do |config|
-  # 
+  #
   # Specify how many retries are allowed on jobs. This number of retries excludes any
   # connectivity error that would be due to the application being down or unreachable.
-  # 
+  #
   # Default: 25
-  # 
+  #
   config.max_retries = 10
 end
 ```
 
 E.g. Set max number of retries to 3 on a given worker
-
-E.g.
 ```ruby
 # app/workers/some_error_worker.rb
 
@@ -580,12 +598,126 @@ class SomeErrorWorker
   # This will override the global setting
   cloudtasker_options max_retries: 3
 
-  def perform()
+  def perform
+    raise(ArgumentError)
+  end
+end
+```
+
+E.g. Evaluate the number of max retries at runtime (target: v0.11.0)
+```ruby
+# app/workers/some_error_worker.rb
+
+class SomeErrorWorker
+  include Cloudtasker::Worker
+
+  # Return the number of max retries based on
+  # worker arguments.
+  #
+  # If this method returns nil then max_retries
+  # will delegate to the class `max_retries` setting or Cloudtasker
+  # `max_retries` configuration otion.
+  def max_retries(arg1, arg2)
+    arg1 == 'foo' ? 13 : nil
+  end
+
+  def perform(arg1, arg2)
     raise(ArgumentError)
   end
 end
 ```
 
+## Testing
+Cloudtasker provides several options to test your workers.
+
+### Test helper setup
+Require `cloudtasker/testing` in your `rails_helper.rb` (Rspec Rails) or `spec_helper.rb` (Rspec) or test unit helper file then enable one of the three modes:
+
+```ruby
+require 'cloudtasker/testing'
+
+# Mode 1 (default): Push jobs to Google Cloud Tasks (env != development) or Redis (env == development)
+Cloudtasker::Testing.enable!
+
+# Mode 2: Push jobs to an in-memory queue. Jobs will not be processed until you call
+# Cloudtasker::Worker.drain_all (process all jobs) or MyWorker.drain (process jobs for specific worker)
+Cloudtasker::Testing.fake!
+
+# Mode 3: Push jobs to an in-memory queue. Jobs will be processed immediately.
+Cloudtasker::Testing.inline!
+```
+
+You can query the current testing mode with:
+```ruby
+Cloudtasker::Testing.enabled?
+Cloudtasker::Testing.fake?
+Cloudtasker::Testing.inline?
+```
+
+Each testing mode accepts a block argument to temporarily switch to it:
+```ruby
+# Enable fake mode for all tests
+Cloudtasker::Testing.fake!
+
+# Enable inline! mode temporarily for a given test
+Cloudtasker.inline! do
+   MyWorker.perform_async(1,2)
+end
+```
+
+Note that extension middlewares - e.g. unique job, batch job etc. - run in test mode. You can disable middlewares in your tests by adding the following to your test helper:
+```ruby
+# Remove all middlewares
+Cloudtasker.configure do |c|
+  c.client_middleware.clear
+  c.server_middleware.clear
+end
+
+# Remove all unique job middlewares
+Cloudtasker.configure do |c|
+  c.client_middleware.remove(Cloudtasker::UniqueJob::Middleware::Client)
+  c.server_middleware.remove(Cloudtasker::UniqueJob::Middleware::Server)
+end
+```
+
+### In-memory queues
+The `fake!` or `inline!` modes use in-memory queues, which can be queried and controlled using the following methods:
+
+```ruby
+# Perform all jobs in queue
+Cloudtasker::Worker.drain_all
+
+# Remove all jobs in queue
+Cloudtasker::Worker.clear_all
+
+# Perform all jobs in queue for a specific worker type
+MyWorker.drain
+
+# Return the list of jobs in queue for a specific worker type
+MyWorker.jobs
+```
+
+### Unit tests
+Below are examples of rspec tests. It is assumed that `Cloudtasker::Testing.fake!` has been set in the test helper.
+
+**Example 1**: Testing that a job is scheduled
+```ruby
+describe 'worker scheduling'
+  subject(:enqueue_job) { MyWorker.perform_async(1,2) }
+
+  it { expect { enqueue_job }.to change(MyWorker.jobs, :size).by(1) }
+end
+```
+
+**Example 2**: Testing job execution logic
+```ruby
+describe 'worker calls api'
+  subject { Cloudtasker::Testing.inline! { MyApiWorker.perform_async(1,2) } }
+
+  before { expect(MyApi).to receive(:fetch).and_return([]) }
+  it { is_expected.to be_truthy }
+end
+```
 
 ## Best practices building workers
 
@@ -661,7 +793,7 @@ Google Cloud Tasks enforces a limit of 100 KB for job payloads. Taking into acco
 Any excessive job payload (> 100 KB) will raise a `Cloudtasker::MaxTaskSizeExceededError`, both in production and development mode.
 
 #### Option 1: Use Cloudtasker optional support for payload storage in Redis
-**Supported since**: `0.10.rc1`
+**Supported since**: `0.10.0`
 
 Cloudtasker provides optional support for storing argument payloads in Redis instead of sending them to Google Cloud Tasks.