busybee 0.2.0 → 0.3.0

checksums.yaml

@@ -1,7 +1,7 @@
 ---
 SHA256:
-  metadata.gz: eeb297a403676c22e7055dbb550d541c6f12fbc29f16caa8550bc625b6265857
-  data.tar.gz: 2a0930162e3b589cf65c85ded384b4b6e2c8100a45da3213c40dac324b5b340d
+  metadata.gz: a3bba732da4bc16cfdcf50a8ad7815d8c5dd45d7ae71d5e2978ebe7ba357d1f9
+  data.tar.gz: 33cf8753e76eedc975b779185fd38134597a198ef4c8522b090fcfb4d600d390
 SHA512:
-  metadata.gz: 7ab1f433f8c1266d9a45c966ec4819f6eb1565c00e3013f44f96d3072dc173f50cd41e8c725f588cc9b19026995e0820700bea4e2adb18fb006181ae6a809e27
-  data.tar.gz: b92c2655751b7bf4070c5fa3bd55ea70a0d687f5725786763c55bdb7b470622c5d567b6c74362831f93963c2e639ecae9878a588164a552605e7c16209a314d7
+  metadata.gz: 5d068b139505b17f1b91cfdd86c53420c284133507e0dd3263a00236708abb261b0b2318524bbff816cbbf9407961d00610a8d35dab438f7a7b268ade9595f39
+  data.tar.gz: aeb232681e9084912c491e3baee068b189975822eead0bfeaaa8907ed1ca72325db699c84d69fc523495a652a604cfe5a836d86571badc83274a91e00b5259ad

data/CHANGELOG.md

@@ -1,12 +1,47 @@
 # Changelog
 
+## v0.3.0 (2026-03-13)
+
+Worker Pattern Framework and CLI, with testing helpers and YAML configuration support.
+
+### New Features:
+
+- **Worker Pattern** (`Busybee::Worker`) – Define job handlers as Ruby classes with a clean DSL:
+  - Declarative inputs (`variable`, `header`) and outputs with type hints, defaults, and validation
+  - Accessor methods for inputs – use `order_id` directly in `perform` instead of `variables[:order_id]`
+  - Automatic job completion on success and failure reporting on exception (`complete_job_on_success`, `fail_job_on_error`)
+  - Manual lifecycle control via `complete!`, `fail!`, `throw_bpmn_error!` for complex flows
+  - Configurable `shutdown_on` for exceptions that should trigger graceful process shutdown (e.g., `PG::ConnectionBad`)
+  - Per-worker configuration via DSL (`worker_mode`, `polling`, `streaming`, `job_timeout`, `backoff`, `backpressure_delay`)
+
+- **CLI** (`bundle exec busybee`) – Run workers as long-lived processes:
+  - Positional args: `busybee Worker1 Worker2 Worker3`
+  - YAML config: `busybee --config config/busybee.yml`
+  - Flags: `--worker-mode`, `--log-format`, `--worker-name`, `--cluster-address`
+  - Automatic Rails environment loading (skip with `BUSYBEE_SKIP_RAILS=1`)
+  - Graceful shutdown on INT/TERM/QUIT; force shutdown on second signal
+
+- **Three Worker Modes:**
+  - **Polling** – long-polls the Zeebe gateway for available jobs
+  - **Streaming** – persistent gRPC stream for lowest-latency job delivery, with optional in-memory buffer and throttle
+  - **Hybrid** (default) – combines streaming with polling to handle both new jobs and pre-existing backlogs while still guaranteeing sequential execution
+
+- **Multiple Workers:** – run multiple worker classes in a single process, each in its own thread with independently-resolved configuration
+
+- **YAML Configuration** – define workers and per-worker configuration in a config file. Top-level settings apply to all workers; per-worker overrides take precedence
+
+- **Worker Testing Helpers:**
+  - `execute_worker(WorkerClass, variables: {...})` – run a worker's full lifecycle against a test job without Zeebe
+  - `build_test_job(variables: {...})` – construct a test job backed by a stub client for state inspection
+  - RSpec matchers: `complete_job(job)`, `fail_job(job)`, `throw_bpmn_error_on(job)` with chainable assertions (`.with_vars`, `.with_error`, `.with_code`)
+
 ## v0.2.0 (2026-02-05)
 
 Production-ready Client API with Rails integration.
 
 ### New Features:
 
-- **Client class** (`Busybee::Client`) - a Ruby-idiomatic wrapper around the Zeebe gRPC API:
+- **Client Class** (`Busybee::Client`) - a Ruby-idiomatic wrapper around the Zeebe gRPC API:
   - Pluggable authentication with four credential types: `Insecure`, `TLS`, `OAuth`, and `CamundaCloud`
     - Automatic credential type detection from parameters
   - Almost all GRPC operations, including `deploy_process`, `start_instance`, `cancel_instance`, `publish_message`, `broadcast_signal` `set_variables`, `resolve_incident`, `complete_job`, `fail_job`, `throw_bpmn_error`, `update_job_retries`, `update_job_timeout`
@@ -17,14 +52,15 @@ Production-ready Client API with Rails integration.
     - Action methods: `complete!`, `fail!`, `throw_bpmn_error!`
   - Variable serialization handles ActiveRecord or other custom objects
 
-- **Rails integration** - Automatic configuration from `config.x.busybee.*`, works seamlessly with Rails secrets
+- **Rails Integration** - Automatic configuration from `config.x.busybee.*`, works seamlessly with Rails secrets
   - Defaults to using Rails logger
   - Structured logs with a `[busybee]` prefix, supporting text or JSON modes
 
 ### Breaking Changes:
 
-- **Testing helpers** now use `Busybee.cluster_address` instead of `Busybee::Testing.address`, which has been removed
-- **Testing::Helpers** was refactored for namespace safety and some methods are no longer accessible within specs
+- **Testing::Helpers:**
+  - Now uses `Busybee.cluster_address` instead of `Busybee::Testing.address`, which has been removed
+  - Was refactored for namespace safety and some methods are no longer accessible within specs
 
 ## v0.1.0 (2025-12-29)
 
@@ -32,7 +68,7 @@ Initial public release with foundational components for testing BPMN workflows.
 
 ### New Features:
 
-- **Testing module** (`Busybee::Testing`) - RSpec helpers and matchers for testing BPMN workflows against Zeebe:
+- **Testing Module** (`Busybee::Testing`) - RSpec helpers and matchers for testing BPMN workflows against Zeebe:
   - `deploy_process` - Deploy BPMN files with optional unique IDs for test isolation
   - `with_process_instance` - Create process instances with automatic cleanup
   - `activate_job` / `activate_jobs` - Activate jobs for assertions
@@ -42,7 +78,7 @@ Initial public release with foundational components for testing BPMN workflows.
   - `ActivatedJob` fluent API with `expect_variables`, `expect_headers`, `and_complete`, `and_fail`, `and_throw_error_event`
   - RSpec matchers: `have_activated`, `have_received_variables`, `have_received_headers`
 
-- **GRPC layer** (`Busybee::GRPC`) - Generated protocol buffer classes from the Zeebe 8.8 proto definition for direct Zeebe API access
+- **GRPC Layer** (`Busybee::GRPC`) - Generated protocol buffer classes from the Zeebe 8.8 proto definition for direct Zeebe API access
 
 ## v0.0.1 (2025-12-03)
 

data/README.md

@@ -18,7 +18,7 @@ Busybee provides everything you need to work with Camunda Platform or self-hoste
 |---------|---------|--------|
 | v0.1 | BPMN Testing Tools, GRPC Layer | Available now! |
 | v0.2 | Client, Rails Integration | Available now! |
-| v0.3 | Worker Pattern & CLI | Early 2026 |
+| v0.3 | Worker Pattern & CLI | Available now! |
 | v0.4 | Instrumentation Hooks, Deployment Tools | Mid 2026 |
 | v1.0 | Production Polish | Late 2026 |
 
@@ -44,35 +44,48 @@ gem install busybee
 
 ## Usage
 
-### Worker Pattern Framework (coming in early 2026)
+### Worker Pattern Framework (available now!)
 
-Define job handlers as Ruby classes. Busybee manages the process lifecycle, the connection to Camunda Cloud, and requesting jobs from Zeebe. If you've used Racecar to build Kafka handlers, or Sidekiq to build background jobs, this should feel very familiar.
-
-> This feature is still being designed. The example shown here is only representative and will change before implementation.
+Define job handlers as Ruby classes. Busybee manages the process lifecycle, the connection to Camunda Cloud, and requesting jobs from Zeebe. If you've used Sidekiq to build background jobs, this should feel very familiar.
 
 ```ruby
 class ProcessOrderWorker < Busybee::Worker
-  type "process-order"
+  job_type "process_order"
 
-  input :order_id, required: true
-  input :customer_email
+  variable :order_id, type: :uuid
+  variable :customer_email, required: false
 
-  output :confirmation_number
+  output :confirmation_number, type: :string
 
   def perform
-    confirmation = OrderService.process(order_id)
-    complete(confirmation_number: confirmation)
+    order = Order.find(order_id)
+    confirmation = order.process!
+    EmailService.send_confirmation(customer_email, confirmation) if customer_email
+    { confirmation_number: confirmation }
   end
 end
 ```
 
-Planned capabilities:
+Run workers from the command line:
+
+```bash
+bundle exec busybee ProcessOrderWorker ShipOrderWorker
+
+# Or with a YAML config file
+bundle exec busybee --config config/busybee.yml
+```
+
+Capabilities:
+
+- Declarative input/output definitions with validation and accessor methods
+- Automatic job completion and failure reporting
+- Three worker modes (polling, streaming, hybrid) for different workload patterns
+- Configurable timeouts, retry backoff, and backpressure handling
+- Graceful shutdown on SIGTERM/SIGINT
+- YAML configuration with per-worker overrides
+- RSpec matchers for unit testing workers without Zeebe
 
-- Declarative input/output definitions with validation
-- Automatic job activation and completion
-- Configurable timeouts and retry behavior
-- Graceful shutdown on SIGTERM
-- CLI for running workers: `bundle exec busybee work` or similar
+**[Full worker documentation &rarr;](docs/workers.md)**
 
 ### Idiomatic Zeebe Client (available now!)
 
@@ -97,7 +110,7 @@ client.publish_message("payment-received",
   vars: { amount: 99.99 }
 )
 
-# Process jobs
+# Process jobs (for ad-hoc use; for production job processing, use the Worker pattern above)
 client.with_each_job("send-confirmation") do |job|
   EmailService.send(job.variables.customer_email)
   job.complete!(sent_at: Time.now.iso8601)
@@ -165,9 +178,9 @@ end
 - `assert_process_completed!` - Verify workflow reached an end event
 - `have_activated`, `have_received_variables`, `have_received_headers` - RSpec matchers
 
-**For more info, see our [full testing documentation here](docs/testing.md).**
+**For more info, see our [full testing documentation here](docs/testing.md).** For unit testing workers, see [Workers: Testing Workers](docs/workers.md#testing-workers).
 
-### Deployment Tools (coming in early 2026)
+### Deployment Tools (coming in mid 2026)
 
 CI/CD tooling for deploying BPMN processes to your Zeebe clusters. Version tracking, environment-specific deployments, and pre-deployment validation.
 
@@ -192,6 +205,10 @@ puts response.brokers.map(&:host)
 
 **For more info, see the [full GRPC documentation here](docs/grpc.md).**
 
+### Demo Application
+
+The [Dropship Co. demo app](spec/demo/README.md) is a multi-domain Rails application that showcases busybee in action. It orchestrates order fulfillment across warehousing, logistics, and delivery services using BPMN workflows and busybee workers. It's a good place to see realistic usage patterns and to experiment with the framework.
+
 ## Ruby Implementation Support
 
 Busybee currently only supports MRI (CRuby). This is due to the state of `grpc` support on other implementations. JRuby is not supported because it cannot run C extensions (it would require `grpc-java` with a Ruby wrapper). TruffleRuby's C extension support is experimental and the `grpc` gem does not currently build on it.

data/docs/client.md

@@ -199,7 +199,7 @@ This means if you start a streaming worker after jobs have already been created,
 - Use `with_each_job` in a polling loop, or
 - Call `with_each_job` at startup to drain existing jobs, then switch to streaming
 
-> Coming in v0.3, the Worker pattern framework will make it easy to select between these behaviors automatically.
+> The [Worker pattern framework](workers.md) makes it easy to select between these behaviors automatically via [worker modes](workers.md#worker-modes).
 
 ### The Job Object
 

data/docs/configuration.md

@@ -1,6 +1,8 @@
-# Configuration
+# Gem Configuration
 
-Busybee provides a flexible configuration system that adapts to different environments - from local development with Docker to production deployments with Camunda Cloud. Configuration can be set through Ruby code, environment variables, or Rails configuration, with sensible defaults that work out of the box.
+Busybee provides a flexible configuration system that adapts to different environments — from local development with Docker to production deployments with Camunda Cloud. Configuration can be set through Ruby code, environment variables, or Rails configuration, with sensible defaults that work out of the box.
+
+This document covers gem-level settings: connection, credentials, logging, and operation defaults. For worker runtime configuration (CLI flags, YAML files, worker modes, and the config precedence chain), see [Workers: Running Workers](workers.md#running-workers).
 
 ## Quick Start
 
@@ -96,7 +98,7 @@ Busybee.cluster_address = "zeebe.example.com:443"
 
 #### `credential_type`
 
-Explicitly selects the credential type. When set, `Credentials.build` uses this type rather than auto-detecting from parameters.
+Explicitly selects the credential type. When set, Busybee uses this type to build Credentials rather than auto-detecting from the provided parameters.
 
 | | |
 |--|--|
@@ -238,6 +240,34 @@ Default backoff time when failing a job, in milliseconds. Individual `fail_job`
 Busybee.default_fail_job_backoff = 10_000  # 10 seconds
 ```
 
+#### `default_job_request_timeout`
+
+Default timeout for job activation requests, in milliseconds. This controls how long the Zeebe gateway waits for jobs to become available before returning an empty response. Individual `with_each_job` and `activate_job` calls can override this.
+
+| | |
+|--|--|
+| **Type** | Integer (milliseconds) or ActiveSupport::Duration |
+| **Default** | `60_000` (60 seconds) |
+
+```ruby
+Busybee.default_job_request_timeout = 30_000   # 30 seconds
+Busybee.default_job_request_timeout = 30.seconds
+```
+
+#### `default_job_lock_timeout`
+
+Default lock timeout for activated jobs, in milliseconds. This controls how long a worker has to process a job before the lock expires and the job becomes available to other workers. Individual `with_each_job` and `open_job_stream` calls can override this.
+
+| | |
+|--|--|
+| **Type** | Integer (milliseconds) or ActiveSupport::Duration |
+| **Default** | `60_000` (60 seconds) |
+
+```ruby
+Busybee.default_job_lock_timeout = 120_000   # 2 minutes
+Busybee.default_job_lock_timeout = 2.minutes
+```
+
 #### `worker_name`
 
 Identifier for this worker instance, used in job activation. Useful for debugging which worker processed a job.
@@ -319,6 +349,16 @@ All module-level configuration attributes can be set via `config.x.busybee.*`:
 | `config.x.busybee.grpc_retry_errors` | `Busybee.grpc_retry_errors` |
 | `config.x.busybee.default_message_ttl` | `Busybee.default_message_ttl` |
 | `config.x.busybee.default_fail_job_backoff` | `Busybee.default_fail_job_backoff` |
+| `config.x.busybee.default_job_request_timeout` | `Busybee.default_job_request_timeout` |
+| `config.x.busybee.default_job_lock_timeout` | `Busybee.default_job_lock_timeout` |
+| `config.x.busybee.default_worker_mode` | `Busybee.default_worker_mode` |
+| `config.x.busybee.default_max_jobs` | `Busybee.default_max_jobs` |
+| `config.x.busybee.default_buffer` | `Busybee.default_buffer` |
+| `config.x.busybee.default_buffer_throttle` | `Busybee.default_buffer_throttle` |
+| `config.x.busybee.default_backpressure_delay` | `Busybee.default_backpressure_delay` |
+| `config.x.busybee.default_input_required` | `Busybee.default_input_required` |
+| `config.x.busybee.default_output_required` | `Busybee.default_output_required` |
+| `config.x.busybee.shutdown_on_errors` | `Busybee.shutdown_on_errors` |
 
 **Credential configuration:**
 
@@ -393,3 +433,118 @@ Busybee.logger = nil           # Disables logging
 ```
 
 This is primarily useful in tests to ensure clean state between examples.
+
+## Worker Defaults
+
+These settings control the default behavior of [workers](workers.md) and how they get jobs from the workflow engine. Each can be overridden per-worker via the [Worker DSL](workers.md#dsl-quick-reference) or at deploy time via [CLI/YAML configuration](workers.md#configuration-precedence).
+
+#### `default_worker_mode`
+
+Default worker mode for workers.
+
+| | |
+|--|--|
+| **Type** | Symbol |
+| **Default** | `:hybrid` |
+| **Valid values** | `:polling`, `:streaming`, `:hybrid` |
+
+```ruby
+Busybee.default_worker_mode = :polling
+```
+
+See [Workers: Worker Modes](workers.md#worker-modes) for details on each mode.
+
+#### `default_max_jobs`
+
+Default maximum number of jobs to fetch per polling request.
+
+| | |
+|--|--|
+| **Type** | Integer |
+| **Default** | `25` |
+
+```ruby
+Busybee.default_max_jobs = 50
+```
+
+#### `default_buffer`
+
+Whether streaming mode buffers jobs in memory by default.
+
+| | |
+|--|--|
+| **Type** | Boolean |
+| **Default** | `true` |
+
+```ruby
+Busybee.default_buffer = false
+```
+
+#### `default_buffer_throttle`
+
+Default throttle delay for the job buffer in streaming or hybrid modes.
+
+| | |
+|--|--|
+| **Type** | Numeric (milliseconds), Boolean, or `nil` |
+| **Default** | `false` (no throttling) |
+
+`false` disables throttling. `true` coerces to `0` (minimal throttle). A positive number sets the delay in milliseconds (sub-millisecond Floats accepted).
+
+```ruby
+Busybee.default_buffer_throttle = 5  # 5ms throttle delay
+```
+
+See [Workers: Buffer Throttle](workers.md#buffer-throttle) for guidance on choosing a value.
+
+#### `default_backpressure_delay`
+
+How long to wait after a backpressure error (`GRPC::ResourceExhausted`) before retrying.
+
+| | |
+|--|--|
+| **Type** | Integer (milliseconds) or ActiveSupport::Duration |
+| **Default** | `2_000` (2 seconds) |
+
+```ruby
+Busybee.default_backpressure_delay = 10_000
+```
+
+#### `default_input_required`
+
+Whether worker inputs are required by default.
+
+| | |
+|--|--|
+| **Type** | Boolean |
+| **Default** | `true` |
+
+```ruby
+Busybee.default_input_required = false  # inputs are optional unless explicitly required
+```
+
+#### `default_output_required`
+
+Whether worker outputs are required by default.
+
+| | |
+|--|--|
+| **Type** | Boolean |
+| **Default** | `true` |
+
+```ruby
+Busybee.default_output_required = false
+```
+
+#### `shutdown_on_errors`
+
+Exception classes that trigger a graceful worker shutdown when raised during `perform`. Applies to all workers in addition to any per-worker `shutdown_on` declarations.
+
+| | |
+|--|--|
+| **Type** | Array of Exception classes (or a single class, which is coerced to an Array) |
+| **Default** | `[]` |
+
+```ruby
+Busybee.shutdown_on_errors = [PG::ConnectionBad, Redis::ConnectionError]
+```

data/docs/grpc.md

@@ -8,7 +8,7 @@ Most users should use one of Busybee's higher-level abstractions:
 
 - **Testing your workflows?** Busybee::Testing provides [RSpec matchers and helpers for BPMN files](./testing.md).
 - **Building apps which manage process instances?** Busybee::Client provides a [Ruby-idiomatic API for all those operations](./client.md).
-- **Processing jobs?** Busybee::Worker (coming in v0.3) will provide an out-of-the-box job worker framework, akin to Sidekiq or Racecar.
+- **Processing jobs?** Busybee::Worker provides an [out-of-the-box job worker framework](./workers.md), akin to Sidekiq or Racecar.
 
 This GRPC layer is an escape hatch for any edge cases you may encounter which need direct access to Zeebe APIs that the higher-level abstractions don't expose. Examples might include:
 

data/docs/testing.md

@@ -1,6 +1,8 @@
-# Testing BPMN Workflows with Busybee
+# Testing BPMN Workflows
 
-Busybee provides RSpec helpers and matchers for testing BPMN workflows against Zeebe. This testing module makes it easy to write integration tests that deploy processes, create instances, activate jobs, and verify workflow behavior.
+Busybee provides RSpec helpers and matchers for testing BPMN workflows against a running Zeebe instance. This testing module lets you deploy processes, create instances, activate jobs, and verify that your workflow definitions route work correctly.
+
+This document covers **workflow-level testing** — verifying that your BPMN process definitions behave as expected. If you're looking to **unit test your worker classes** (the Ruby code that handles individual jobs), see [Workers: Testing Workers](workers.md#testing-workers). The two complement each other: workflow tests verify the orchestration, worker tests verify the business logic.
 
 ## Installation
 
@@ -41,19 +43,20 @@ Configure the Zeebe connection. Busybee reads from environment variables by defa
 Busybee.configure do |config|
   config.cluster_address = "localhost:26500"
 end
-
-# Testing-specific options
-Busybee::Testing.configure do |config|
-  config.activate_request_timeout = 2000 # milliseconds, default: 1000
-end
 ```
 
-### Configuration Options
+Job activation timeouts used by the testing helpers default to `Busybee.default_job_request_timeout` (see [Configuration](configuration.md)). You can override per-call or globally:
 
-| Option | Environment Variable | Default | Description |
-|--------|---------------------|---------|-------------|
-| `cluster_address` | `CLUSTER_ADDRESS` | `"localhost:26500"` | Zeebe gateway gRPC address (via `Busybee.configure`) |
-| `activate_request_timeout` | - | `1000` | Timeout in milliseconds for job activation requests (via `Busybee::Testing.configure`) |
+```ruby
+# Per-call: pass timeout directly to the helper
+job = activate_job("my-task", timeout: 2000)
+jobs = activate_jobs("my-task", max_jobs: 5, timeout: 2000)
+
+# Globally: configure a shorter default for your test environment
+Busybee.configure do |config|
+  config.default_job_request_timeout = 2000 # milliseconds, default: 60_000
+end
+```
 
 For authenticated cluster connections (TLS, OAuth, Camunda Cloud), configure credentials via `Busybee.configure` in your Rails `config/environments/test.rb` or equivalent. See [Providing Credentials](client.md#providing-credentials) for details.
 
@@ -185,7 +188,7 @@ Activates a single job of the specified type. Raises `Busybee::Testing::NoJobAva
 
 **Parameters:**
 - `type` (String) - Job type to activate
-- `timeout` (Integer, ActiveSupport::Duration, optional) - Request timeout in milliseconds. Defaults to `Busybee::Testing.activate_request_timeout` (1000ms)
+- `timeout` (Integer, ActiveSupport::Duration, optional) - Request timeout in milliseconds. Defaults to `Busybee.default_job_request_timeout` (60,000ms)
 
 **Returns:** `ActivatedJob` instance
 
@@ -209,7 +212,7 @@ Activates multiple jobs of the specified type.
 **Parameters:**
 - `type` (String) - Job type to activate
 - `max_jobs` (Integer) - Maximum number of jobs to activate
-- `timeout` (Integer, ActiveSupport::Duration, optional) - Request timeout in milliseconds. Defaults to `Busybee::Testing.activate_request_timeout` (1000ms)
+- `timeout` (Integer, ActiveSupport::Duration, optional) - Request timeout in milliseconds. Defaults to `Busybee.default_job_request_timeout` (60,000ms)
 
 **Returns:** Enumerator of `ActivatedJob` instances
 
@@ -719,18 +722,20 @@ cancel_instance(key) # Easy to forget in error paths
 Assert expected inputs before completing jobs:
 
 ```ruby
-# Good: Verify then complete
-job = activate_job("send-email")
-expect(job).to have_received_variables(
-  recipient: "user@example.com",
-  template: "order_confirmation"
-)
-job.mark_completed(sent_at: Time.now.iso8601)
-
-# Also Good: fluent style
+# Good: fluent style — verify and complete in one chain
 activate_job("send-email")
   .expect_variables(recipient: "user@example.com")
   .and_complete(sent_at: Time.now.iso8601)
+
+# Also Good: separate verification and completion — useful when you need to
+# activate multiple jobs of the same type and distinguish between them
+jobs = activate_jobs("send-comms", max_jobs: 2)
+  .group_by { |j| j.headers["medium"] }
+  .transform_values(&:first)
+
+expect(jobs["sms"]).to have_received_variables(template: "order_sms")
+expect(jobs["email"]).to have_received_variables(template: "order_confirmation")
+jobs.each_value(&:mark_completed)
 ```
 
 ## Troubleshooting