cloudtasker 0.10.rc8 → 0.10.0

checksums.yaml

@@ -1,7 +1,7 @@
 ---
 SHA256:
-  metadata.gz: 9d8d250dbd0e47a0e1f102a131dd831d44d4db4272c5aa429caa0c27d00cf4f7
-  data.tar.gz: 4e6ea0c77b8be277e74e1a54d227389fd61c9568cedddcdbb94d3fc9c1a6788e
+  metadata.gz: 0a7bb0597bbd5656c6c6c273b4a65097c0b9c44be4b5944a5c1fbdf2d03f9c7c
+  data.tar.gz: c1e1d33203c8dfa5a090427c91f7b94e6046fbc0037fbb74285e61851cab3f93
 SHA512:
-  metadata.gz: 8fdeafa8bfcb2f50695faaca28618f572d1610bfb15acd63b9766cd46c0449171384dc4eaef459b1b68cfc50700acb321fd4bbfde20664311f899bcdc1db9d58
-  data.tar.gz: 59ba684ad2a9358904cc6a7d6fcce46f5ae3e48d1cded624f77145b552a7693914552230fb7e210832b681c7cbb47b2a413ddd40eb8fba560a734e385b4b8a2b
+  metadata.gz: a03d48359589520a040e8214ed40d778aece0e667de81bfb15b447c4f4f93f296955b08624c9fa1a5e8ca5e5cb6773389b490566f076f0e1f50ebbf0c46d376a
+  data.tar.gz: 5f64a1e30faa954e2e046f787c216b9c02a992493561abe5dbbef9a7678833ef1644947b4e6f3743ebe43c79c62d90c48b46c91a6002088f88e94e7689b91a6d

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:
@@ -38,4 +38,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/CHANGELOG.md

@@ -1,5 +1,30 @@
 # Changelog
 
+## [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)

data/README.md

@@ -250,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
   #
@@ -508,7 +508,7 @@ 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.rc6`
+**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.
 
@@ -571,7 +571,7 @@ 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 `v0.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
@@ -772,7 +772,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.
 

data/lib/cloudtasker/version.rb

@@ -1,5 +1,5 @@
 # frozen_string_literal: true
 
 module Cloudtasker
-  VERSION = '0.10.rc8'
+  VERSION = '0.10.0'
 end

metadata

@@ -1,14 +1,14 @@
 --- !ruby/object:Gem::Specification
 name: cloudtasker
 version: !ruby/object:Gem::Version
-  version: 0.10.rc8
+  version: 0.10.0
 platform: ruby
 authors:
 - Arnaud Lachaume
 autorequire: 
 bindir: exe
 cert_chain: []
-date: 2020-06-24 00:00:00.000000000 Z
+date: 2020-09-02 00:00:00.000000000 Z
 dependencies:
 - !ruby/object:Gem::Dependency
   name: activesupport
@@ -392,9 +392,9 @@ required_ruby_version: !ruby/object:Gem::Requirement
       version: '0'
 required_rubygems_version: !ruby/object:Gem::Requirement
   requirements:
-  - - ">"
+  - - ">="
     - !ruby/object:Gem::Version
-      version: 1.3.1
+      version: '0'
 requirements: []
 rubygems_version: 3.0.0
 signing_key: