{"id":15288779,"url":"https://github.com/keypup-io/cloudtasker","last_synced_at":"2025-05-15T09:06:01.759Z","repository":{"id":36464405,"uuid":"219153033","full_name":"keypup-io/cloudtasker","owner":"keypup-io","description":"Background jobs for Ruby using Google Cloud Tasks","archived":false,"fork":false,"pushed_at":"2025-05-08T15:17:22.000Z","size":1751,"stargazers_count":159,"open_issues_count":12,"forks_count":40,"subscribers_count":6,"default_branch":"master","last_synced_at":"2025-05-15T04:09:29.312Z","etag":null,"topics":["background-jobs","cloud-tasks","cloudtasker","cron-jobs","gcp-cloud-tasks","google-cloud-platform","google-cloud-tasks","rails","ruby"],"latest_commit_sha":null,"homepage":"","language":"Ruby","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":"mit","status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/keypup-io.png","metadata":{"files":{"readme":"README.md","changelog":"CHANGELOG.md","contributing":null,"funding":null,"license":"LICENSE.txt","code_of_conduct":"CODE_OF_CONDUCT.md","threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null,"governance":null,"roadmap":null,"authors":null,"dei":null,"publiccode":null,"codemeta":null,"zenodo":null}},"created_at":"2019-11-02T12:49:35.000Z","updated_at":"2025-04-17T20:30:26.000Z","dependencies_parsed_at":"2023-11-20T19:28:59.939Z","dependency_job_id":"e60d67ff-4aaf-4a25-9b7a-5c3c468936aa","html_url":"https://github.com/keypup-io/cloudtasker","commit_stats":{"total_commits":392,"total_committers":9,"mean_commits":43.55555555555556,"dds":"0.34693877551020413","last_synced_commit":"17719d571bdf9d8df2baaf0b03899af1fda4f9bf"},"previous_names":[],"tags_count":53,"template":false,"template_full_name":null,"repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/keypup-io%2Fcloudtasker","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/keypup-io%2Fcloudtasker/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/keypup-io%2Fcloudtasker/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/keypup-io%2Fcloudtasker/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/keypup-io","download_url":"https://codeload.github.com/keypup-io/cloudtasker/tar.gz/refs/heads/master","host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":254310513,"owners_count":22049468,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2022-07-04T15:15:14.044Z","host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":["background-jobs","cloud-tasks","cloudtasker","cron-jobs","gcp-cloud-tasks","google-cloud-platform","google-cloud-tasks","rails","ruby"],"created_at":"2024-09-30T15:53:09.549Z","updated_at":"2025-05-15T09:06:01.729Z","avatar_url":"https://github.com/keypup-io.png","language":"Ruby","readme":"![Build Status 3.x](https://github.com/keypup-io/cloudtasker/actions/workflows/test_ruby_3.x.yml/badge.svg) [![Gem Version](https://badge.fury.io/rb/cloudtasker.svg)](https://badge.fury.io/rb/cloudtasker)\n\n# Cloudtasker\n\nBackground jobs for Ruby using Google Cloud Tasks.\n\nCloudtasker 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.\n\nCloudtasker 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.\n\nCloudtasker also provides optional modules for running [cron jobs](docs/CRON_JOBS.md), [batch jobs](docs/BATCH_JOBS.md), [unique jobs](docs/UNIQUE_JOBS.md) and [storable jobs](docs/STORABLE_JOBS.md).\n\nA local processing server is also available for development. This local server processes jobs in lieu of Cloud Tasks and allows you to work offline.\n\n## Summary\n\n1. [Installation](#installation)\n2. [Get started with Rails](#get-started-with-rails)\n2. [Get started with Rails \u0026 ActiveJob](#get-started-with-rails--activejob)\n3. [Configuring Cloudtasker](#configuring-cloudtasker)\n    1. [Cloud Tasks authentication \u0026 permissions](#cloud-tasks-authentication--permissions)\n    2. [Cloudtasker initializer](#cloudtasker-initializer)\n4. [Enqueuing jobs](#enqueuing-jobs)\n5. [Managing worker queues](#managing-worker-queues)\n    1. [Creating queues](#creating-queues)\n    2. [Assigning queues to workers](#assigning-queues-to-workers)\n6. [Extensions](#extensions)\n7. [Working locally](#working-locally)\n    1. [Option 1: Cloudtasker local server](#option-1-cloudtasker-local-server)\n    2. [Option 2: Using ngrok](#option-2-using-ngrok)\n8. [Logging](#logging)\n    1. [Configuring a logger](#configuring-a-logger)\n    2. [Logging context](#logging-context)\n    3. [Truncating log arguments](#truncating-log-arguments)\n    4. [Searching logs: Job ID vs Task ID](#searching-logs-job-id-vs-task-id)\n9. [Error Handling](#error-handling)\n    1. [HTTP Error codes](#http-error-codes)\n    2. [Worker callbacks](#worker-callbacks)\n    3. [Global callbacks](#global-callbacks)\n    4. [Max retries](#max-retries)\n    5. [Conditional reenqueues using retry errors](#conditional-reenqueues-using-retry-errors)\n    6. [Dispatch deadline](#dispatch-deadline)\n10. [Testing](#testing)\n    1. [Test helper setup](#test-helper-setup)\n    2. [In-memory queues](#in-memory-queues)\n    3. [Unit tests](#unit-tests)\n11. [Best practices building workers](#best-practices-building-workers)\n\n## Installation\n\nAdd this line to your application's Gemfile:\n\n```ruby\ngem 'cloudtasker'\n```\n\nAnd then execute:\n\n    $ bundle\n\nOr install it yourself with:\n\n    $ gem install cloudtasker\n\n## Get started with Rails\n\nCloudtasker is pre-integrated with Rails. Follow the steps below to get started.\n\nInstall redis on your machine (this is required by the Cloudtasker local processing server)\n```bash\n# E.g. using brew\nbrew install redis\n```\n\nAdd the following initializer\n```ruby\n# config/initializers/cloudtasker.rb\n\nCloudtasker.configure do |config|\n  #\n  # Adapt the server port to be the one used by your Rails web process\n  #\n  config.processor_host = 'http://localhost:3000'\n\n  #\n  # If you do not have any Rails secret_key_base defined, uncomment the following\n  # This secret is used to authenticate jobs sent to the processing endpoint\n  # of your application.\n  #\n  # config.secret = 'some-long-token'\nend\n```\n\nDefine your first worker:\n```ruby\n# app/workers/dummy_worker.rb\n\nclass DummyWorker\n  include Cloudtasker::Worker\n\n  def perform(some_arg)\n    logger.info(\"Job run with #{some_arg}. This is working!\")\n  end\nend\n```\n\nLaunch Rails and the local Cloudtasker processing server (or add `cloudtasker` to your foreman config as a `worker` process)\n```bash\n# In one terminal\n\u003e rails s -p 3000\n\n# In another terminal\n\u003e cloudtasker\n```\n\nOpen a Rails console and enqueue some jobs\n```ruby\n  # Process job as soon as possible\n  DummyWorker.perform_async('foo')\n\n  # Process job in 60 seconds\n  DummyWorker.perform_in(60, 'foo')\n```\n\nYour Rails logs should display the following:\n```log\nStarted POST \"/cloudtasker/run\" for ::1 at 2019-11-22 09:20:09 +0100\n\nProcessing by Cloudtasker::WorkerController#run as */*\n  Parameters: {\"worker\"=\u003e\"DummyWorker\", \"job_id\"=\u003e\"d76040a1-367e-4e3b-854e-e05a74d5f773\", \"job_args\"=\u003e[\"foo\"], \"job_meta\"=\u003e{}}\n\nI, [2019-11-22T09:20:09.319336 #49257]  INFO -- [Cloudtasker][d76040a1-367e-4e3b-854e-e05a74d5f773] Starting job...: {:worker=\u003e\"DummyWorker\", :job_id=\u003e\"d76040a1-367e-4e3b-854e-e05a74d5f773\", :job_meta=\u003e{}}\nI, [2019-11-22T09:20:09.319938 #49257]  INFO -- [Cloudtasker][d76040a1-367e-4e3b-854e-e05a74d5f773] Job run with foo. This is working!: {:worker=\u003e\"DummyWorker\", :job_id=\u003e\"d76040a1-367e-4e3b-854e-e05a74d5f773\", :job_meta=\u003e{}}\nI, [2019-11-22T09:20:09.320966 #49257]  INFO -- [Cloudtasker][d76040a1-367e-4e3b-854e-e05a74d5f773] Job done: {:worker=\u003e\"DummyWorker\", :job_id=\u003e\"d76040a1-367e-4e3b-854e-e05a74d5f773\", :job_meta=\u003e{}}\n```\n\nThat's it! Your job was picked up by the Cloudtasker local server and sent for processing to your Rails web process.\n\nNow jump to the next section to configure your app to use Google Cloud Tasks as a backend.\n\n## Get started with Rails \u0026 ActiveJob\n**Note**: ActiveJob is supported since `0.11.0`  \n**Note**: Cloudtasker extensions (cron, batch, unique jobs and storable) are not available when using cloudtasker via ActiveJob.\n\nCloudtasker is pre-integrated with ActiveJob. Follow the steps below to get started.\n\nInstall redis on your machine (this is required by the Cloudtasker local processing server)\n```bash\n# E.g. using brew\nbrew install redis\n```\n\nAdd the following initializer\n```ruby\n# config/initializers/cloudtasker.rb\n\nCloudtasker.configure do |config|\n  #\n  # Adapt the server port to be the one used by your Rails web process\n  #\n  config.processor_host = 'http://localhost:3000'\n\n  #\n  # If you do not have any Rails secret_key_base defined, uncomment the following\n  # This secret is used to authenticate jobs sent to the processing endpoint\n  # of your application.\n  #\n  # config.secret = 'some-long-token'\nend\n```\n\nConfigure ActiveJob to use Cloudtasker. You can also configure ActiveJob per environment via the config/environments/:env.rb files\n```ruby\n# config/application.rb\n\nrequire_relative 'boot'\nrequire 'rails/all'\n\nBundler.require(*Rails.groups)\n\nmodule Dummy\n  class Application \u003c Rails::Application\n    # Initialize configuration defaults for originally generated Rails version.\n    config.load_defaults 6.0\n\n    # Settings in config/environments/* take precedence over those specified here.\n    # Application configuration can go into files in config/initializers\n    # -- all .rb files in that directory are automatically loaded after loading\n    # the framework and any gems in your application.\n\n    # Use cloudtasker as the ActiveJob backend:\n    config.active_job.queue_adapter = :cloudtasker\n  end\nend\n\n```\n\nDefine your first job:\n```ruby\n# app/jobs/example_job.rb\n\nclass ExampleJob \u003c ApplicationJob\n  queue_as :default\n\n  def perform(some_arg)\n    logger.info(\"Job run with #{some_arg}. This is working!\")\n  end\nend\n```\n\nLaunch Rails and the local Cloudtasker processing server (or add `cloudtasker` to your foreman config as a `worker` process)\n```bash\n# In one terminal\n\u003e rails s -p 3000\n\n# In another terminal\n\u003e cloudtasker\n```\n\nOpen a Rails console and enqueue some jobs\n```ruby\n  # Process job as soon as possible\n  ExampleJob.perform_later('foo')\n\n  # Process job in 60 seconds\n  ExampleJob.set(wait: 60).perform_later('foo')\n```\n\n\n## Configuring Cloudtasker\n\n### Cloud Tasks authentication \u0026 permissions\n\nThe Google Cloud library authenticates via the Google Cloud SDK by default. If you do not have it setup then we recommend you [install it](https://cloud.google.com/sdk/docs/quickstarts).\n\nOther options are available such as using a service account. You can see all authentication options in the [Google Cloud Authentication guide](https://github.com/googleapis/google-cloud-ruby/blob/main/AUTHENTICATION.md).\n\nIn order to function properly Cloudtasker requires the authenticated account to have the following IAM permissions:\n- `cloudtasks.tasks.get`\n- `cloudtasks.tasks.create`\n- `cloudtasks.tasks.delete`\n\nTo get started quickly you can add the `roles/cloudtasks.admin` role to your account via the [IAM Console](https://console.cloud.google.com/iam-admin/iam). This is not required if your account is a project admin account.\n\nThe GCP project ID and region values are not loaded automatically by the Google Cloud library, and must be explicitly defined in the initializer when using Google Cloud Tasks.\n\n### Cloudtasker initializer\n\nThe gem can be configured through an initializer. See below all the available configuration options.\n\n```ruby\n# config/initializers/cloudtasker.rb\n\nCloudtasker.configure do |config|\n  #\n  # If you do not have any Rails secret_key_base defined, uncomment the following.\n  # This secret is used to authenticate jobs sent to the processing endpoint\n  # of your application.\n  #\n  # Default with Rails: Rails.application.credentials.secret_key_base\n  #\n  # config.secret = 'some-long-token'\n\n  #\n  # Specify the details of your Google Cloud Task location. \n  # \n  # This is required when the mode of operation is set to :production\n  # \n  config.gcp_location_id = 'us-central1' # defaults to 'us-east1'\n  config.gcp_project_id = 'my-gcp-project'\n\n  #\n  # Specify the namespace for your Cloud Task queues.\n  #\n  # Specifying a namespace is optional but strongly recommended to keep\n  # queues organised, especially in a micro-service environment.\n  #\n  # The gem assumes that a least a default queue named 'my-app-default'\n  # exists in Cloud Tasks. You can create this default queue using the\n  # gcloud SDK or via the `rake cloudtasker:setup_queue` task if you use Rails.\n  #\n  # Workers can be scheduled on different queues. The name of the queue\n  # in Cloud Tasks is always assumed to be prefixed with the prefix below.\n  #\n  # E.g.\n  # Setting `cloudtasker_options queue: 'critical'` on a worker means that\n  # the worker will be pushed to 'my-app-critical' in Cloud Tasks.\n  #\n  # Specific queues can be created in Cloud Tasks using the gcloud SDK or\n  # via the `rake cloudtasker:setup_queue name=\u003cqueue_name\u003e` task.\n  #\n  config.gcp_queue_prefix = 'my-app'\n\n  #\n  # Specify the publicly accessible host for your application\n  #\n  # \u003e E.g. in development, using the cloudtasker local server\n  # config.processor_host = 'http://localhost:3000'\n  #\n  # \u003e E.g. in development, using `config.mode = :production` and ngrok\n  # config.processor_host = 'https://111111.ngrok.io'\n  #\n  config.processor_host = 'https://app.mydomain.com'\n\n  #\n  # Specify the mode of operation:\n  # - :development =\u003e jobs will be pushed to Redis and picked up by the Cloudtasker local server\n  # - :production =\u003e jobs will be pushed to Google Cloud Tasks. Requires a publicly accessible domain.\n  #\n  # Defaults to :development unless CLOUDTASKER_ENV or RAILS_ENV or RACK_ENV is set to something else.\n  #\n  # config.mode = Rails.env.production? || Rails.env.my_other_env? ? :production : :development\n\n  #\n  # Specify the logger to use\n  #\n  # Default with Rails: Rails.logger\n  # Default without Rails: Logger.new(STDOUT)\n  #\n  # config.logger = MyLogger.new(STDOUT)\n\n  #\n  # Specify how many retries are allowed on jobs. This number of retries excludes any\n  # connectivity error due to the application being down or unreachable.\n  #\n  # Default: 25\n  #\n  # config.max_retries = 10\n\n  #\n  # Specify the redis connection hash.\n  #\n  # This is ONLY required in development for the Cloudtasker local server and in\n  # all environments if you use any cloudtasker extension (unique jobs, cron jobs,\n  # batch jobs or storable jobs)\n  #\n  # See https://github.com/redis/redis-rb for examples of configuration hashes.\n  #\n  # Default: redis-rb connects to redis://127.0.0.1:6379/0\n  #\n  # config.redis = { url: 'redis://localhost:6379/5' }\n\n  #\n  # Set to true to store job arguments in Redis instead of sending arguments as part\n  # of the job payload to Google Cloud Tasks.\n  #\n  # This is useful if you expect to process jobs with payloads exceeding 100KB, which\n  # is the limit enforced by Google Cloud Tasks.\n  #\n  # You can set this configuration parameter to a KB value if you want to store jobs\n  # args in redis only if the JSONified arguments payload exceeds that threshold.\n  #\n  # Supported since: v0.10.0\n  #\n  # Default: false\n  #\n  # Store all job payloads in Redis:\n  # config.store_payloads_in_redis = true\n  #\n  # Store all job payloads in Redis exceeding 50 KB:\n  # config.store_payloads_in_redis = 50\n\n  #\n  # Specify the dispatch deadline for jobs in Cloud Tasks, in seconds.\n  # Jobs taking longer will be retried by Cloud Tasks, even if they eventually\n  # complete on the server side.\n  #\n  # Note that this option is applied when jobs are enqueued job. Changing this value\n  # will not impact already enqueued jobs.\n  #\n  # This option can also be configured on a per worker basis via\n  # the cloudtasker_options directive.\n  #\n  # Supported since: v0.12.0\n  #\n  # Default: 600 seconds (10 minutes)\n  # Min: 15 seconds\n  # Max: 1800 seconds (30 minutes)\n  #\n  # config.dispatch_deadline = 600\n\n  #\n  # Specify a proc to be invoked every time a job fails due to a runtime\n  # error.\n  #\n  # This hook is not invoked for DeadWorkerError. See on_dead instead.\n  #\n  # This is useful when you need to apply general exception handling, such\n  # as reporting errors to a third-party service like Rollbar or Bugsnag.\n  #\n  # Note: the worker argument might be nil, such as when InvalidWorkerError is raised.\n  #\n  # Supported since: v0.12.0\n  # \n  # Default: no operation\n  #\n  # config.on_error = -\u003e(error, worker) { Rollbar.error(error) }\n\n  #\n  # Specify a proc to be invoked every time a job dies due to too many\n  # retries.\n  #\n  # This is useful when you need to apply general exception handling, such\n  # logging specific messages/context when a job dies.\n  #\n  # Supported since: v0.12.0\n  # \n  # Default: no operation\n  #\n  # config.on_dead = -\u003e(error, worker) { Rollbar.error(error) }\n\n  #\n  # Specify the Open ID Connect (OIDC) details to connect to a protected GCP service, such\n  # as a private Cloud Run application.\n  #\n  # The configuration supports the following details:\n  # - service_account_email: This is the \"act as\" user. It can be found under the security details\n  #   of the Cloud Run service.\n  # - audience: The audience is usually the publicly accessible host for the Cloud Run service\n  #   (which is the same value configured as the processor_host). If no audiences are provided\n  #   it will be set to the processor_host.\n  #\n  # Note: If the OIDC token is used for a Cloud Run service make sure to include the\n  # `iam.serviceAccounts.actAs` permission on the service account.\n  #\n  # See https://cloud.google.com/tasks/docs/creating-http-target-tasks#sa for more information on\n  # setting up service accounts for use with Cloud Tasks.\n  #\n  # Supported since: v0.14.0\n  #\n  # Default: nil \n  #\n  # config.oidc = { service_account_email: 'example@gserviceaccount.com' }\n  # config.oidc = { service_account_email: 'example@gserviceaccount.com', audience: 'https://api.example.net' }\n\n  #\n  # Enable/disable the verification of SSL certificates on the local processing server when\n  # sending tasks to the processor.\n  #\n  # Set to false to disable SSL verification (OpenSSL::SSL::VERIFY_NONE).\n  #\n  # Default: true\n  #\n  # config.local_server_ssl_verify = true\nend\n```\n\nIf the default queue `\u003cgcp_queue_prefix\u003e-default` does not exist in Cloud Tasks you should [create it using the gcloud sdk](https://cloud.google.com/tasks/docs/creating-queues).\n\nAlternatively with Rails you can simply run the following rake task if you have queue admin permissions (`cloudtasks.queues.get` and `cloudtasks.queues.create`).\n```bash\nbundle exec rake cloudtasker:setup_queue\n```\n\n## Enqueuing jobs\n\nCloudtasker provides multiple ways of enqueuing jobs.\n\n```ruby\n# Worker will be processed as soon as possible\nMyWorker.perform_async(arg1, arg2)\n\n# Worker will be processed in 5 minutes\nMyWorker.perform_in(5 * 60, arg1, arg2)\n# or with Rails\nMyWorker.perform_in(5.minutes, arg1, arg2)\n\n# Worker will be processed on a specific date\nMyWorker.perform_at(Time.parse('2025-01-01 00:50:00Z'), arg1, arg2)\n# also with Rails\nMyWorker.perform_at(3.days.from_now, arg1, arg2)\n\n# With all options, including which queue to run the worker on.\nMyWorker.schedule(args: [arg1, arg2], time_at: Time.parse('2025-01-01 00:50:00Z'), queue: 'critical')\n# or\nMyWorker.schedule(args: [arg1, arg2], time_in: 5 * 60, queue: 'critical')\n```\n\nCloudtasker 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.\n\nE.g.\n```ruby\n# app/workers/fetch_resource_worker.rb\n\nclass FetchResourceWorker\n  include Cloudtasker::Worker\n\n  def perform(id)\n    # ...do some logic...\n    if some_condition\n      # Stop and re-enqueue the job to be run again in 10 seconds.\n      # Also see the section on Cloudtasker::RetryWorkerError for a different\n      # approach on reenqueuing.\n      return reenqueue(10)\n    else\n      # ...keep going...\n    end\n  end\nend\n```\n\n## Managing worker queues\n\nCloudtasker allows you to manage several queues and distribute workers across them based on job priority. By default jobs are pushed to the `default` queue, which is `\u003cgcp_queue_prefix\u003e-default` in Cloud Tasks.\n\n### Creating queues\n\nMore queues can be created using the gcloud sdk or the `cloudtasker:setup_queue` rake task.\n\nE.g. Create a `critical` queue with a concurrency of 5 via the gcloud SDK\n```bash\ngcloud tasks queues create \u003cgcp_queue_prefix\u003e-critical --max-concurrent-dispatches=5\n```\n\nE.g. Create a `real-time` queue with a concurrency of 15 via the rake task (Rails only)\n```bash\nrake cloudtasker:setup_queue name=real-time concurrency=15\n```\n\nWhen running the Cloudtasker local processing server, you can specify the concurrency for each queue using:\n```bash\ncloudtasker -q critical,5 -q important,4 -q default,3\n```\n\n### Assigning queues to workers\n\nQueues can be assigned to workers via the `cloudtasker_options` directive on the worker class:\n\n```ruby\n# app/workers/critical_worker.rb\n\nclass CriticalWorker\n  include Cloudtasker::Worker\n\n  cloudtasker_options queue: :critical\n\n  def perform(some_arg)\n    logger.info(\"This is a critical job run with arg=#{some_arg}.\")\n  end\nend\n```\n\nQueues can also be assigned at runtime when scheduling a job:\n```ruby\nCriticalWorker.schedule(args: [1], queue: :important)\n```\n\n## Extensions\n**Note**: Extensions are not available when using cloudtasker via ActiveJob.\n\nCloudtasker comes with three optional features:\n- Cron Jobs [[docs](docs/CRON_JOBS.md)]: Run jobs at fixed intervals.\n- Batch Jobs [[docs](docs/BATCH_JOBS.md)]: Run jobs in jobs and track completion of the overall batch.\n- Unique Jobs [[docs](docs/UNIQUE_JOBS.md)]: Ensure uniqueness of jobs based on job arguments.\n- Storable Jobs [[docs](docs/STORABLE_JOBS.md)]: Park jobs until they are ready to be enqueued.\n\n## Working locally\n\nCloudtasker pushes jobs to Google Cloud Tasks, which in turn sends jobs for processing to your application via HTTP POST requests to the `/cloudtasker/run` endpoint of the publicly accessible domain of your application.\n\nWhen working locally on your application it is usually not possible to have a public domain. So what are the options?\n\n### Option 1: Cloudtasker local server\nThe Cloudtasker local server is a ruby daemon that looks for jobs pushed to Redis and sends them to your application via HTTP POST requests. The server mimics the way Google Cloud Tasks works, but locally!\n\nYou can configure your application to use the Cloudtasker local server using the following initializer:\n```ruby\n# config/initializers/cloudtasker.rb\n\nCloudtasker.configure do |config|\n  # ... other options\n\n  # Push jobs to redis and let the Cloudtasker local server collect them\n  # This is the default mode unless CLOUDTASKER_ENV or RAILS_ENV or RACK_ENV is set\n  # to a non-development environment\n  config.mode = :development\nend\n```\n\nThe Cloudtasker server can then be started using:\n```bash\nbundle exec cloudtasker\n```\n\nYou can as well define a Procfile to manage the cloudtasker process via foreman. Then use `foreman start` to launch both your Rails server and the Cloudtasker local server.\n```yaml\n# Procfile\nweb: bundle exec rails s\nworker: bundle exec cloudtasker\n```\n\nNote that the local development server runs with `5` concurrent threads by default. You can tune the number of threads per queue by running `cloudtasker` the following options:\n```bash\nbundle exec cloudtasker -q critical,5 -q important,4 -q default,3\n```\n\n### Option 2: Using ngrok\n\nWant to test your application end to end with Google Cloud Task? Then [ngrok](https://ngrok.io) is the way to go.\n\nFirst start your ngrok tunnel:\n```bash\nngrok http 3000\n```\n\nTake note of your ngrok domain and configure Cloudtasker to use Google Cloud Task in development via ngrok.\n```ruby\n# config/initializers/cloudtasker.rb\n\nCloudtasker.configure do |config|\n  # Specify your Google Cloud Task queue configuration\n  config.gcp_location_id = 'us-central1'\n  config.gcp_project_id = 'my-gcp-project'\n  config.gcp_queue_prefix = 'my-app'\n\n  # Use your ngrok domain as the processor host\n  config.processor_host = 'https://your-tunnel-id.ngrok.io'\n\n  # Force Cloudtasker to use Google Cloud Tasks in development\n  config.mode = :production\nend\n```\n\nFinally start Rails to accept jobs from Google Cloud Tasks\n```bash\nbundle exec rails s\n```\n\n## Logging\nThere are several options available to configure logging and logging context.\n\n### Configuring a logger\nCloudtasker uses `Rails.logger` if Rails is available and falls back on a plain ruby logger `Logger.new(STDOUT)` if not.\n\nIt is also possible to configure your own logger. For example you can setup Cloudtasker with [semantic_logger](http://rocketjob.github.io/semantic_logger) by doing the following in your initializer:\n```ruby\n# config/initializers/cloudtasker.rb\n\nCloudtasker.configure do |config|\n  config.logger = SemanticLogger[Cloudtasker]\nend\n```\n\n### Logging context\nCloudtasker provides worker contextual information to the worker `logger` method inside your worker methods.\n\nFor example:\n```ruby\n# app/workers/dummy_worker.rb\n\nclass DummyWorker\n  include Cloudtasker::Worker\n\n  def perform(some_arg)\n    logger.info(\"Job run with #{some_arg}. This is working!\")\n  end\nend\n```\n\nWill generate the following log with context `{:worker=\u003e ..., :job_id=\u003e ..., :job_meta=\u003e ...}`\n```log\n[Cloudtasker][d76040a1-367e-4e3b-854e-e05a74d5f773] Job run with foo. This is working!: {:worker=\u003e\"DummyWorker\", :job_id=\u003e\"d76040a1-367e-4e3b-854e-e05a74d5f773\", :job_meta=\u003e{}, :task_id =\u003e \"4e755d3f-6de0-426c-b4ac-51edd445c045\"}\n```\n\nThe 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).\n\nContextual information can be customised globally and locally using a log context_processor. By default the `Cloudtasker::WorkerLogger` is configured the following way:\n```ruby\nCloudtasker::WorkerLogger.log_context_processor = -\u003e(worker) { worker.to_h.slice(:worker, :job_id, :job_meta, :job_queue, :task_id) }\n```\n\nYou can decide to add a global identifier for your worker logs using the following:\n```ruby\n# config/initializers/cloudtasker.rb\n\nCloudtasker::WorkerLogger.log_context_processor = lambda { |worker|\n  worker.to_h.slice(:worker, :job_id, :job_meta, :job_queue, :task_id).merge(app: 'my-app')\n}\n```\n\nYou could also decide to log all available context - including arguments passed to `perform` - for specific workers only:\n```ruby\n# app/workers/full_context_worker.rb\n\nclass FullContextWorker\n  include Cloudtasker::Worker\n\n  cloudtasker_options log_context_processor: -\u003e(worker) { worker.to_h }\n\n  def perform(some_arg)\n    logger.info(\"This log entry will have full context!\")\n  end\nend\n```\n\nSee the [Cloudtasker::Worker class](lib/cloudtasker/worker.rb) for more information on attributes available to be logged in your `log_context_processor` proc.\n\n### Truncating log arguments\n**Supported since**: `v0.14.0`  \n\nBy default Cloudtasker does not log job arguments as arguments can contain sensitive data and generate voluminous logs, which may lead to noticeable costs with your log provider (e.g. GCP Logging). Also some providers (e.g. GCP Logging) will automatically truncate log entries that are too big and reduce their searchability.\n\nJob arguments can be logged for all workers by configuring the following log context processor in your Cloudtasker initializer:\n```ruby\nCloudtasker::WorkerLogger.log_context_processor = -\u003e(worker) { worker.to_h }\n```\n\nIn order to reduce the size of logged job arguments, the following `truncate` utility is provided by Cloudtasker: \n```ruby\n# string_limit: The maximum size for strings. Default is 64. Set to -1 to disable.\n# array_limit: The maximum length for arrays. Default is 10. Set to -1 to disable.\n# max_depth: The maximum recursive depth. Default is 3. Set to -1 to disable.\nCloudtasker::WorkerLogger.truncate(payload, string_limit: 64, array_limit: 10, max_depth: 3)\n```\n\nYou may use it the following way:\n```ruby\nCloudtasker::WorkerLogger.log_context_processor = lambda do |worker|\n  payload = worker.to_h\n\n  # Using default options\n  payload[:job_args] = Cloudtasker::WorkerLogger.truncate(payload[:job_args])\n\n  # Using custom options\n  # payload[:job_args] = Cloudtasker::WorkerLogger.truncate(payload[:job_args], string_limit: 32, array_limit: 5, max_depth: 2)\n\n  # Return the payload to log\n  payload\nend\n```\n\nTo further reduce logging cost, you may also log a reasonably complete version of job arguments at start then log a watered down version for the remaining log entries:\n```ruby\nCloudtasker::WorkerLogger.log_context_processor = lambda do |worker|\n  payload = worker.to_h\n\n  # Adjust the log payload based on the lifecycle of the job\n  payload[:job_args] = if worker.perform_started_at\n                         # The job start has already been logged. Log the job primitive arguments without depth.\n                         # Arrays and hashes will be masked.\n                         Cloudtasker::WorkerLogger.truncate(payload[:job_args], max_depth: 0)\n                       else\n                         # This is the job start. Log a more complete version of the job args.\n                         Cloudtasker::WorkerLogger.truncate(payload[:job_args])\n                       end\n\n  # Return the payload to log\n  payload\nend\n```\n\n### Searching logs: Job ID vs Task ID\n**Note**: `task_id` field is available in logs starting with `0.10.0`\n\nJob 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.\n\n| Field | Definition |\n|------|-------------|\n| `job_id` | This ID is generated by Cloudtasker. It identifies the job along its entire lifecyle. It is persistent across retries and reschedules. |\n| `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. |\n\nThe 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:\n1. Use a task ID to lookup the logs of a specific job instance in Stackdriver Logging (or any other logging solution).\n2. From (1) you can retrieve the `job_id` attribute of the job.\n3. From (2) you can use the `job_id` to lookup the job logs along its entire lifecycle.\n\n## Error Handling\n\nJobs 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.\n\n### HTTP Error codes\n\nJobs failing will automatically return the following HTTP error code to Cloud Tasks, based on the actual reason:\n\n| Code | Description |\n|------|-------------|\n| 204 | The job was processed successfully |\n| 205 | The job is dead and has been removed from the queue |\n| 404 | The job has specified an incorrect worker class.  |\n| 422 | An error happened during the execution of the worker (`perform` method) |\n\n### Worker callbacks\n\nWorkers can implement the `on_error(error)` and `on_dead(error)` callbacks to do things when a job fails during its execution:\n\nE.g.\n```ruby\n# app/workers/handle_error_worker.rb\n\nclass HandleErrorWorker\n  include Cloudtasker::Worker\n\n  def perform\n    raise(ArgumentError)\n  end\n\n  # The runtime error is passed as an argument.\n  def on_error(error)\n    logger.error(\"The following error happened: #{error}\")\n  end\n\n  # The job has been retried too many times and will be removed\n  # from the queue.\n  def on_dead(error)\n    logger.error(\"The job died with the following error: #{error}\")\n  end\nend\n```\n\n### Global callbacks\n**Supported since**: `0.12.0`  \n\nIf you need to apply general exception handling logic to your workers you can specify `on_error` and `on_dead` hooks in the Cloudtasker configuration.\n\nThis is useful if you need to report errors to third-party services such as Rollbar or Bugsnag.\n\n```ruby\n# config/initializers/cloudtasker.rb\n\nCloudtasker.configure do |config|\n  #\n  # Report runtime and dead worker errors to Rollbar\n  #\n  config.on_error = -\u003e (error, _worker) { Rollbar.error(error) }\n  config.on_dead = -\u003e (error, _worker) { Rollbar.error(error) }\nend\n```\n\n### Max retries\n\nBy default jobs are retried 25 times - using an exponential backoff - before being declared dead. This number of retries can be customized locally on workers and/or globally via the Cloudtasker initializer.\n\nNote 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.\n\n**Note**: Versions prior to `v0.14.0` use the `X-CloudTasks-TaskRetryCount` header for retries instead of the `X-CloudTasks-TaskExecutionCount` header to detect the number of retries, because there a previous bug on the GCP side which made the `X-CloudTasks-TaskExecutionCount` stay at zero instead of increasing on successive executions. Versions prior to `v0.14.0` count any failure as failure, including failures due to the backend being unavailable (`HTTP 503`). Versions `v0.14.0` and later only count application failure (`HTTP 4xx`) as failure for retry purpose.\n\nE.g. Set max number of retries globally via the cloudtasker initializer.\n```ruby\n# config/initializers/cloudtasker.rb\n\nCloudtasker.configure do |config|\n  #\n  # Specify how many retries are allowed on jobs. This number of retries excludes any\n  # connectivity error that would be due to the application being down or unreachable.\n  #\n  # Default: 25\n  #\n  config.max_retries = 10\nend\n```\n\nE.g. Set max number of retries to 3 on a given worker\n```ruby\n# app/workers/some_error_worker.rb\n\nclass SomeErrorWorker\n  include Cloudtasker::Worker\n\n  # This will override the global setting\n  cloudtasker_options max_retries: 3\n\n  def perform\n    raise(ArgumentError)\n  end\nend\n```\n\nE.g. Evaluate the number of max retries at runtime (Supported since: v0.10.1)\n```ruby\n# app/workers/some_error_worker.rb\n\nclass SomeErrorWorker\n  include Cloudtasker::Worker\n\n  # Return the number of max retries based on\n  # worker arguments.\n  #\n  # If this method returns nil then max_retries\n  # will delegate to the class `max_retries` setting or Cloudtasker\n  # `max_retries` configuration otion.\n  def max_retries(arg1, arg2)\n    arg1 == 'foo' ? 13 : nil\n  end\n\n  def perform(arg1, arg2)\n    raise(ArgumentError)\n  end\nend\n```\n\n### Conditional reenqueues using retry errors\n**Supported since**: `v0.14.0`  \n\nIf your worker is waiting for some precondition to occur and you want to re-enqueue it until the condition has been met, you can raise a `Cloudtasker::RetryWorkerError`. This special error will fail your job **without logging an error** while still increasing the number of retries.\n\nThis is a safer approach than using the `reenqueue` helper, which can lead to forever running jobs if not used properly.\n\n```ruby\n# app/workers/my_worker.rb\n\nclass MyWorker\n  include Cloudtasker::Worker\n\n  def perform(project_id)\n    # Abort if project does not exist\n    return unless (project = Project.find_by(id: project_id))\n\n    # Trigger a retry if the project is still in \"discovering\" status\n    # This error will NOT log an error. It only triggers a retry.\n    raise Cloudtasker::RetryWorkerError if project.status == 'discovering'\n\n    # The previous approach was to use `reenqueue`. This works but since it\n    # does not increase the number of retries, you may end up with forever running\n    # jobs\n    # return reenqueue(10) if project.status == 'discovering'\n\n    # Do stuff when project is not longer discovering\n    do_some_stuff\n  end\n\n  # You can then specify what should be done if we've been waiting for too long\n  def on_dead(error)\n    logger.error(\"Looks like the project is forever discovering. Time to give up.\")\n\n    # This is of course an imaginary method\n    send_slack_notification_to_internal_support_team(worker: self.class, args: job_args)\n  end\nend\n```\n\n### Dispatch deadline\n**Supported since**: `0.12.0`  \n\nBy default Cloud Tasks will automatically timeout your jobs after 10 minutes, independently of your server HTTP timeout configuration.\n\nYou can modify the dispatch deadline for jobs at a global level or on a per job basis.\n\nE.g. Set the default dispatch deadline to 20 minutes.\n```ruby\n# config/initializers/cloudtasker.rb\n\nCloudtasker.configure do |config|\n  #\n  # Specify the dispatch deadline for jobs in Cloud Tasks, in seconds. \n  # Jobs taking longer will be retried by Cloud Tasks, even if they eventually\n  # complete on the server side.\n  #\n  # Note that this option is applied when jobs are enqueued job. Changing this value\n  # will not impact already enqueued jobs.\n  #\n  # Default: 600 (10 minutes)\n  #\n  config.dispatch_deadline = 20 * 60 # 20 minutes\nend\n```\n\nE.g. Set a dispatch deadline of 5 minutes on a specific worker\n```ruby\n# app/workers/some_error_worker.rb\n\nclass SomeFasterWorker\n  include Cloudtasker::Worker\n\n  # This will override the global setting\n  cloudtasker_options dispatch_deadline: 5 * 60\n\n  def perform\n    # ... do things ...\n  end\nend\n```\n\n## Testing\nCloudtasker provides several options to test your workers.\n\n### Test helper setup\nRequire `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:\n\n```ruby\nrequire 'cloudtasker/testing'\n\n# Mode 1 (default): Push jobs to Google Cloud Tasks (env != development) or Redis (env == development)\nCloudtasker::Testing.enable!\n\n# Mode 2: Push jobs to an in-memory queue. Jobs will not be processed until you call\n# Cloudtasker::Worker.drain_all (process all jobs) or MyWorker.drain (process jobs for specific worker)\nCloudtasker::Testing.fake!\n\n# Mode 3: Push jobs to an in-memory queue. Jobs will be processed immediately.\nCloudtasker::Testing.inline!\n```\n\nYou can query the current testing mode with:\n```ruby\nCloudtasker::Testing.enabled?\nCloudtasker::Testing.fake?\nCloudtasker::Testing.inline?\n```\n\nEach testing mode accepts a block argument to temporarily switch to it:\n```ruby\n# Enable fake mode for all tests\nCloudtasker::Testing.fake!\n\n# Enable inline! mode temporarily for a given test\nCloudtasker::Testing.inline! do\n   MyWorker.perform_async(1,2)\nend\n```\n\nNote 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:\n```ruby\n# Remove all middlewares\nCloudtasker.configure do |c|\n  c.client_middleware.clear\n  c.server_middleware.clear\nend\n\n# Remove all unique job middlewares\nCloudtasker.configure do |c|\n  c.client_middleware.remove(Cloudtasker::UniqueJob::Middleware::Client)\n  c.server_middleware.remove(Cloudtasker::UniqueJob::Middleware::Server)\nend\n```\n\n### In-memory queues\nThe `fake!` or `inline!` modes use in-memory queues, which can be queried and controlled using the following methods:\n\n```ruby\n# Perform all jobs in queue\nCloudtasker::Worker.drain_all\n\n# Remove all jobs in queue\nCloudtasker::Worker.clear_all\n\n# Perform all jobs in queue for a specific worker type\nMyWorker.drain\n\n# Return the list of jobs in queue for a specific worker type\nMyWorker.jobs\n```\n\n### Unit tests\nBelow are examples of rspec tests. It is assumed that `Cloudtasker::Testing.fake!` has been set in the test helper.\n\n**Example 1**: Testing that a job is scheduled\n```ruby\ndescribe 'worker scheduling'\n  subject(:enqueue_job) { MyWorker.perform_async(1,2) }\n\n  it { expect { enqueue_job }.to change(MyWorker.jobs, :size).by(1) }\nend\n```\n\n**Example 2**: Testing job execution logic\n```ruby\ndescribe 'worker calls api'\n  subject { Cloudtasker::Testing.inline! { MyApiWorker.perform_async(1,2) } }\n\n  before { expect(MyApi).to receive(:fetch).and_return([]) }\n  it { is_expected.to be_truthy }\nend\n```\n\n## Best practices building workers\n\nBelow are recommendations and notes about creating workers.\n\n### Use primitive arguments\nPushing a job via `MyWorker.perform_async(arg1, arg2)` will serialize all arguments as JSON. Cloudtasker does not do any magic marshalling and therefore passing user-defined class instance as arguments is likely to make your jobs fail because of JSON serialization/deserialization.\n\nWhen defining your worker `perform` method, use primitive arguments (integers, strings, hashes).\n\nDon't do that:\n```ruby\n# app/workers/user_email_worker.rb\n\nclass UserEmailWorker\n  include Cloudtasker::Worker\n\n  def perform(user)\n    user.reload.send_email\n  end\nend\n```\n\nDo that:\n```ruby\n# app/workers/user_email_worker.rb\n\nclass UserEmailWorker\n  include Cloudtasker::Worker\n\n  def perform(user_id)\n    User.find_by(id: user_id)\u0026.send_email\n  end\nend\n```\n\n### Assume hash arguments are stringified\nBecause of JSON serialization/deserialization hashes passed to `perform_*` methods will eventually be passed as stringified hashes to the worker `perform` method.\n\n```ruby\n# Enqueuing a job with:\nMyWorker.perform_async({ foo: 'bar', 'baz' =\u003e { key: 'value' } })\n\n# will be processed as\nMyWorker.new.perform({ 'foo' =\u003e 'bar', 'baz' =\u003e { 'key' =\u003e 'value' } })\n```\n\n### Be careful with default arguments\nDefault arguments passed to the `perform` method are not actually considered as job arguments. Default arguments will therefore be ignored in contextual logging and by extensions relying on arguments such as the [unique job](docs/UNIQUE_JOBS.md) extension.\n\nConsider the following worker:\n```ruby\n# app/workers/user_email_worker.rb\n\nclass UserEmailWorker\n  include Cloudtasker::Worker\n\n  cloudtasker_options lock: :until_executed\n\n  def perform(user_id, time_at = Time.now.iso8601)\n    User.find_by(id: user_id)\u0026.send_email(Time.parse(time_at))\n  end\nend\n```\n\nIf you enqueue this worker by omitting the second argument `MyWorker.perform_async(123)` then:\n- The `time_at` argument will not be included in contextual logging\n- The `time_at` argument will be ignored by the `unique-job` extension, meaning that job uniqueness will be only based on the `user_id` argument.\n\n### Handling big job payloads\nGoogle Cloud Tasks enforces a limit of 100 KB for job payloads. Taking into accounts Cloudtasker authentication headers and meta information this leave ~85 KB of free space for JSONified job arguments.\n\nAny excessive job payload (\u003e 100 KB) will raise a `Cloudtasker::MaxTaskSizeExceededError`, both in production and development mode.\n\n#### Option 1: Use Cloudtasker optional support for payload storage in Redis\n**Supported since**: `0.10.0`\n\nCloudtasker provides optional support for storing argument payloads in Redis instead of sending them to Google Cloud Tasks.\n\nTo enable it simply put the following in your Cloudtasker initializer:\n```ruby\n# config/initializers/cloudtasker.rb\n\nCloudtasker.configure do |config|\n  # Enable Redis support. Specify your redis connection\n  config.redis = { url: 'redis://localhost:6379/5' }\n\n  # Store all job payloads in Redis:\n  config.store_payloads_in_redis = true\n\n  # OR: store all job payloads in Redis exceeding 50 KB:\n  # config.store_payloads_in_redis = 50\nend\n```\n\n#### Option 2: Do it yourself solution\n\nIf you feel that a job payload is going to get big, prefer to store the payload using a datastore (e.g. Redis) and pass a reference to the job to retrieve the payload inside your job `perform` method.\n\nE.g. Define a job like this\n```ruby\n# app/workers/big_payload_worker.rb\n\nclass BigPayloadWorker\n  include Cloudtasker::Worker\n\n  def perform(payload_id)\n    data = Rails.cache.fetch(payload_id)\n    # ...do some processing...\n  end\nend\n```\n\nThen enqueue your job like this:\n```ruby\n# Fetch and store the payload\ndata = ApiClient.fetch_thousands_of_records\npayload_id = SecureRandom.uuid\nRails.cache.write(payload_id, data)\n\n# Enqueue the processing job\nBigPayloadWorker.perform_async(payload_id)\n```\n\n### Sizing the concurrency of your queues\n\nWhen defining the max concurrency of your queues (`max_concurrent_dispatches` in Cloud Tasks) you must keep in mind the maximum number of threads that your application provides. Otherwise your application threads may eventually get exhausted and your users will experience outages if all your web threads are busy running jobs.\n\n#### With server based applications\n\nLet's consider an application deployed in production with 3 instances, each having `RAILS_MAX_THREADS` set to `20`. This gives us a total of `60` threads available.\n\nNow let's say that we distribute jobs across two queues: `default` and `critical`. We can set the concurrency of each queue depending on the profile of the application:\n\nE.g. 1: The application serves requests from web users and runs backgrounds jobs in a balanced way\n```\nconcurrency for default queue: 20\nconcurrency for critical queue: 10\n\nTotal threads consumed by jobs at most: 30\nTotal threads always available to web users at worst: 30\n```\n\nE.g. 2: The application is a micro-service API heavily focused on running jobs (e.g. data processing)\n```\nconcurrency for default queue: 35\nconcurrency for critical queue: 15\n\nTotal threads consumed by jobs at most: 50\nTotal threads always available to API clients at worst: 10\n```\n\nAlso always ensure that your total number of threads does not exceed the available number of database connections (if you use any).\n\n#### With serverless applications\n\nIn a serverless context your application will be scaled up/down based on traffic. When we say 'traffic' this includes requests from Cloud Tasks to run jobs.\n\nBecause your application is auto-scaled - and assuming you haven't set a maximum - your job processing capacity if theoretically unlimited. The main limiting factor in a serverless context becomes external constraints such as the number of database connections available.\n\nTo size the concurrency of your queues you should therefore take the most limiting factor - which is often the database connection pool size of relational databases - and use the calculations of the previous section with this limiting factor as the capping parameter instead of threads.\n\n\n## Development\n\nAfter checking out the repo, run `bin/setup` to install dependencies.\n\nFor tests, run `rake` to run the tests. Note that Rails is not in context by default, which means Rails-specific test will not run.\nFor tests including Rails-specific tests, run `bundle exec appraisal rails_7.0 rake`\nFor all context-specific tests (incl. Rails), run the [appraisal tests](Appraisals) using `bundle exec appraisal rake`.\n\nYou can run `bin/console` for an interactive prompt that will allow you to experiment.\n\nTo install this gem onto your local machine, run `bundle exec rake install`.\n\nTo release a new version, update the version number in `version.rb`, and then run `bundle exec rake release`, which will create a git tag for the version, push git commits and tags, and push the `.gem` file to [rubygems.org](https://rubygems.org).\n\n## Contributing\n\nBug reports and pull requests are welcome on GitHub at https://github.com/keypup-io/cloudtasker. This project is intended to be a safe, welcoming space for collaboration, and contributors are expected to adhere to the [Contributor Covenant](http://contributor-covenant.org) code of conduct.\n\n## License\n\nThe gem is available as open source under the terms of the [MIT License](https://opensource.org/licenses/MIT).\n\n## Code of Conduct\n\nEveryone interacting in the Cloudtasker project’s codebases, issue trackers, chat rooms and mailing lists is expected to follow the [code of conduct](https://github.com/keypup-io/cloudtasker/blob/master/CODE_OF_CONDUCT.md).\n\n## Author\n\nProvided with :heart: by [keypup.io](https://keypup.io/)\n","funding_links":[],"categories":[],"sub_categories":[],"project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fkeypup-io%2Fcloudtasker","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fkeypup-io%2Fcloudtasker","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fkeypup-io%2Fcloudtasker/lists"}