job-workflow 0.4.0 → 0.6.0

data/guides/API_REFERENCE.md

@@ -18,10 +18,9 @@ task(name, **options, &block)
   - `depends_on` (Symbol | Array[Symbol]): Dependent tasks
   - `each` (Proc): Proc that returns an enumerable for map task execution
   - `enqueue` (Hash | Proc | bool): Controls whether task iterations are enqueued as sub-jobs
-    - Hash format (recommended): `{ condition: Proc, queue: String, concurrency: Integer }`
+    - Hash format (recommended): `{ condition: Proc, queue: String }`
       - `condition` (Proc | bool): Determines if task should be enqueued (default: true if Hash is not empty)
       - `queue` (String): Custom queue name for the task (optional)
-      - `concurrency` (Integer): Concurrency limit for parallel processing (default: unlimited)
     - Proc format (legacy): Proc that returns boolean
     - bool format: true/false for simple cases
     - Default: nil (synchronous execution)
@@ -75,7 +74,8 @@ end
 # Parallel processing with collection
 task :process_items,
      each: ->(ctx) { ctx.arguments.items },
-     enqueue: { concurrency: 5 },
+     enqueue: true,
+     throttle: 5,
      output: { result: "String" } do |ctx|
   item = ctx.each_value
   { result: ProcessService.handle(item) }
@@ -84,6 +84,76 @@ end
 
 **Map Task Output**: When `each:` is specified, outputs are automatically collected as an array.
 
+### Task continuation helpers
+
+Inside a task body, you can read the current task cursor, store a new cursor, and create interruption points through the task context.
+
+#### Regular task example
+
+```ruby
+task :sync_pages, output: { processed: "Integer" } do |ctx|
+  page = ctx.cursor || 1
+  result = ExternalAPI.fetch(page:)
+
+  ctx.set_cursor!(page + 1) if result.next_page?
+
+  { processed: result.items.size }
+end
+```
+
+- `ctx.cursor` returns the current task cursor, or `nil` when no cursor has been stored
+- `ctx.set_cursor!(value)` validates that `value` is ActiveJob-serializable, stores it in the current continuation step, and checkpoints the job through Active Job continuation
+- `ctx.checkpoint!` creates a checkpoint without changing the public cursor value
+- Call `ctx.set_cursor!` when you want to change the public cursor value and create a checkpoint at the same time
+- Call `ctx.checkpoint!` when you want the current task execution to become interruptible without changing the public cursor value
+- Outside task execution, `ctx.cursor` returns `nil`, and `ctx.set_cursor!` / `ctx.checkpoint!` raise an error
+
+For regular tasks, a cursor is only persisted when you call `ctx.set_cursor!(value)` explicitly.
+
+#### Checkpoint without changing the cursor
+
+```ruby
+task :publish_report do |ctx|
+  report = build_report
+  ctx.checkpoint!
+  deliver_report(report)
+end
+```
+
+#### Repeating work inside a task
+
+```ruby
+task :sync_users do |ctx|
+  start_index = ctx.cursor || 0
+
+  ctx.arguments.user_ids.drop(start_index).each_with_index do |user_id, offset|
+    sync_user(user_id)
+    ctx.set_cursor!(start_index + offset + 1)
+  end
+end
+```
+
+This pattern is useful when a single task iterates over an Enumerable internally and you want to resume from the last completed item after an interruption.
+
+#### `each:` task example
+
+```ruby
+task :sync_users, each: ->(ctx) { ctx.arguments.user_ids } do |ctx|
+  next_cursor = ExternalAPI.sync_user(
+    user_id: ctx.each_value,
+    cursor: ctx.cursor
+  )
+
+  ctx.set_cursor!(next_cursor) unless next_cursor.nil?
+end
+```
+
+For `each:` tasks, JobWorkflow keeps the existing integer resume behavior for completed iterations.
+
+- If an `each:` task is interrupted after calling `ctx.set_cursor!`, JobWorkflow resumes with both the current iteration index and the saved task cursor
+- If an iteration completes normally, the resume state advances to the next integer index
+- In other words, a custom cursor in an `each:` task is meant for resuming work inside the current iteration, not for replacing the completion index of finished iterations
+
 ### workflow_concurrency
 
 Configure job-level concurrency limits with workflow-aware context.
@@ -117,7 +187,8 @@ class ImportJob < ApplicationJob
 
   task :process,
        each: ->(ctx) { ctx.arguments.items },
-       enqueue: { concurrency: 5 },
+       enqueue: true,
+       throttle: 5,
        output: { result: "String" } do |ctx|
     { result: handle(ctx.each_value) }
   end
@@ -141,7 +212,8 @@ class BatchImportJob < ApplicationJob
 
   task :process,
        each: ->(ctx) { ctx.arguments.items },
-       enqueue: { concurrency: 5 },
+       enqueue: true,
+       throttle: 5,
        output: { result: "String" } do |ctx|
     { result: handle(ctx.each_value) }
   end
@@ -158,7 +230,8 @@ argument :items, "Array[String]"
 
 task :process_items,
      each: ->(ctx) { ctx.arguments.items },
-     enqueue: { concurrency: 5 },
+     enqueue: true,
+     throttle: 5,
      output: { result: "String", status: "Symbol" } do |ctx|
   item = ctx.each_value
   {

data/guides/DEPENDENCY_WAIT.md

@@ -14,7 +14,8 @@ class ExampleJob < ApplicationJob
 
   task :process_items,
        each: ->(ctx) { ctx.arguments.items },
-       enqueue: { concurrency: 5 },
+       enqueue: true,
+       throttle: 5,
        output: { result: "Integer" } do |ctx|
     # This creates many sub-jobs
     { result: ctx.each_value * 2 }
@@ -172,7 +173,8 @@ class DataPipelineJob < ApplicationJob
   # Extract data from multiple sources in parallel
   task :extract_data,
        each: ->(ctx) { %w[users orders products inventory] },
-       enqueue: { concurrency: 4 },
+       enqueue: true,
+       throttle: 4,
        output: { source: "String", count: "Integer" } do |ctx|
     source = ctx.each_value
     data = DataSource.fetch(source, date: ctx.arguments.date)
@@ -210,10 +212,11 @@ class APIAggregatorJob < ApplicationJob
 
   argument :user_ids, "Array[Integer]"
 
-  # Fetch user data with rate limiting
+  # Fetch user data with rate limiting.
+  # Async fan-out is unbounded here; the official execution cap is throttle: 5.
   task :fetch_users,
        each: ->(ctx) { ctx.arguments.user_ids },
-       enqueue: { concurrency: 10 },
+       enqueue: true,
        throttle: { key: "external_api", limit: 5 },
        output: { user_id: "Integer", data: "Hash" } do |ctx|
     user_id = ctx.each_value
@@ -270,7 +273,8 @@ dependency_wait: { poll_timeout: 60, reschedule_delay: 10 }
 # ✅ Good: dependency_wait with parallel sub-jobs
 task :process,
      each: ->(ctx) { ctx.arguments.items },
-     enqueue: { concurrency: 10 } do |ctx|
+     enqueue: true,
+     throttle: 10 do |ctx|
   heavy_process(ctx.each_value)
 end
 

data/guides/MONITORING_UI.md

@@ -0,0 +1,74 @@
+# Monitoring UI
+
+## Overview
+
+JobWorkflow ships with a workflow-oriented monitoring UI. Instead of listing mixed job rows first, the UI starts
+from workflow definitions, then lets you drill into one workflow's root executions and finally into one execution's
+DAG state.
+
+This view is intended to answer workflow-level questions such as:
+
+- which workflow is currently stuck
+- which task is running or failed
+- how `each` fan-out is progressing
+- which arguments and outputs shaped the current execution
+
+## What the UI shows
+
+The current scope includes:
+
+- workflow definition list
+- paginated root execution list per workflow
+- execution detail with a DAG overview, task state, arguments, outputs, and failed task
+- fan-out progress and sub-task job links into Mission Control Jobs
+
+History analytics, retries, and dry-run launch flows are out of scope for now.
+
+## Navigation
+
+The UI is organized around workflows rather than a cross-workflow execution feed:
+
+```text
+workflow definitions
+  └─ one workflow's root executions
+       └─ one root execution with sub-task-job detail
+```
+
+The UI is intentionally scoped to one workflow at a time, so the first screen stays focused on definitions and the
+execution list stays easy to scan.
+
+## Mounting the engine
+
+Add the engine to your application's routes:
+
+```ruby
+# config/routes.rb
+mount JobWorkflow::Monitoring::Engine => "/job_workflow"
+```
+
+After mounting, open `/job_workflow` to browse workflow definitions and executions.
+
+## Authentication and controller inheritance
+
+By default, monitoring controllers inherit from `ApplicationController`. If you already use a dedicated authenticated
+controller for admin tooling, configure monitoring to inherit from it:
+
+```ruby
+config.job_workflow.monitoring.base_controller_class = "AdminController"
+```
+
+If `config.job_workflow.monitoring.base_controller_class` is not set and `MissionControl::Jobs` is installed,
+monitoring falls back to `MissionControl::Jobs.base_controller_class`.
+
+## Root executions and sub-task jobs
+
+Execution lists show **root jobs only**. `SubTaskJob` rows do not appear in the workflow execution list. Instead, the
+detail page shows sub-task job state only after you open one root execution.
+
+This keeps the list view focused on workflow-level monitoring while still preserving the full fan-out story on the
+detail page.
+
+## Query behavior
+
+Root executions are paginated with a cursor and scoped by workflow class. As a user, this means the execution list is
+ordered newest-first within the workflow you selected, without mixing in unrelated job rows.

data/guides/PARALLEL_PROCESSING.md

@@ -54,9 +54,9 @@ task :process_items,
 end
 ```
 
-### Asynchronous Execution with Concurrency
+### Asynchronous Execution with Throttled Concurrency
 
-To execute map task iterations in separate sub-jobs with concurrency control, use the `enqueue:` option with a Hash containing `condition:` and `concurrency:`:
+To execute map task iterations in separate sub-jobs, enable `enqueue:` and use `throttle:` when you need to cap concurrent execution:
 
 ```ruby
 # Simplest form: enable parallel execution with default settings
@@ -69,21 +69,23 @@ end
 # Process up to 10 items concurrently in sub-jobs
 task :process_items,
      each: ->(ctx) { ctx.arguments.items },
-     enqueue: { condition: ->(_ctx) { true }, concurrency: 10 } do |ctx|
+     enqueue: true,
+     throttle: 10 do |ctx|
   process_item(ctx.each_value)
 end
 
-# Simplified syntax when condition is implicitly true
+# Conditional enqueue with a concurrency cap
 task :process_items,
      each: ->(ctx) { ctx.arguments.items },
-     enqueue: { concurrency: 10 } do |ctx|
+     enqueue: { condition: ->(ctx) { ctx.arguments.use_async? } },
+     throttle: 10 do |ctx|
   process_item(ctx.each_value)
 end
 
 # When enqueue is enabled:
 # - Each iteration is executed in a separate sub-job
 # - Sub-jobs are created via perform_all_later
-# - Concurrency limit controls how many sub-jobs run in parallel
+# - `throttle` controls how many iterations can execute concurrently
 # - Parent job waits for all sub-jobs to complete before continuing
 # - Outputs from sub-jobs are automatically collected
 ```
@@ -99,14 +101,18 @@ The `enqueue:` option determines how map task iterations are executed:
 
 - **`enqueue: true`**: Each iteration is enqueued as a separate sub-job with default settings
   - Simplest way to enable parallel execution
-  - No concurrency limit (executes as fast as workers allow)
+  - No throttle limit (executes as fast as workers allow)
   - Good for I/O-bound operations with many workers
 
-- **`enqueue: { condition: ->(_ctx) { true }, concurrency: 10 }`**: Each iteration is enqueued as a separate sub-job
-  - Enables true parallel execution across multiple workers
+- **`enqueue: { condition: ... }`**: Each iteration is enqueued as a separate sub-job when the condition passes
   - Better for I/O-bound operations (API calls, database queries)
-  - Can accept dynamic condition: `enqueue: { condition: ->(ctx) { ctx.arguments.use_concurrency? } }`
-  - Supports `queue:` option for custom queue: `enqueue: { queue: "critical", concurrency: 5 }`
+  - Can accept dynamic condition: `enqueue: { condition: ->(ctx) { ctx.arguments.use_async? } }`
+  - Supports `queue:` option for custom queue: `enqueue: { queue: "critical" }`
+
+- **`throttle: 10`**: Limits how many task executions can run concurrently
+  - This is the official way to cap async map task parallelism
+  - It is enforced at perform time via JobWorkflow semaphores
+  - It does not use SolidQueue `ready` / `blocked` dispatch-state controls
 
 **Note**: `enqueue:` works with both regular tasks and map tasks. For map tasks, it enables asynchronous sub-job execution. For regular tasks, it allows conditional enqueueing as a separate job. Legacy syntax (`enqueue: ->(_ctx) { true }` as a Proc) is still supported for backward compatibility.
 
@@ -129,7 +135,8 @@ class ImportJob < ApplicationJob
 
   task :process_items,
        each: ->(ctx) { ctx.arguments.items },
-       enqueue: { concurrency: 5 },
+       enqueue: true,
+       throttle: 5,
        output: { result: "String" } do |ctx|
     { result: process(ctx.each_value) }
   end
@@ -238,7 +245,8 @@ class DataProcessingJob < ApplicationJob
   task :process_by_region,
        each: ->(ctx) { ctx.arguments.regions },
        output: { region: "String", results: "Array[Hash]" },
-       enqueue: { concurrency: 5 } do |ctx|
+       enqueue: true,
+       throttle: 5 do |ctx|
     region = ctx.each_value
     # This will create sub-tasks for each region
     { region: region, results: [] }
@@ -261,7 +269,8 @@ class DataProcessingJob < ApplicationJob
        },
        depends_on: [:process_by_region],
        output: { region: "String", data_type: "String", result: "Hash" },
-       enqueue: { concurrency: 10 } do |ctx|
+       enqueue: true,
+       throttle: 10 do |ctx|
     item = ctx.each_value
     region = item[:region]
     data_type = item[:data_type]
@@ -290,7 +299,7 @@ DataProcessingJob.perform_later(
   regions: ["us-east-1", "us-west-1", "eu-west-1"],
   data_types: ["user", "order", "product"]
 )
-# => 3 regions × 3 data types = 9 parallel iterations (with concurrency limits)
+# => 3 regions × 3 data types = 9 parallel iterations (with throttled concurrency)
 ```
 
 ### Advanced Matrix with Filtering
@@ -318,7 +327,8 @@ task :process_filtered_matrix,
        end
      },
      output: { region: "String", data_type: "String", status: "Symbol" },
-     enqueue: { concurrency: 10 } do |ctx|
+     enqueue: true,
+     throttle: 10 do |ctx|
   combo = ctx.each_value
   region = combo[:region]
   data_type = combo[:data_type]
@@ -335,9 +345,9 @@ end
 
 When implementing matrix processing:
 
-1. **Concurrency Control**: Set appropriate `concurrency:` limits to avoid overwhelming workers
-   - High concurrency (20+): Suitable for I/O-bound operations (API calls, database queries)
-   - Low concurrency (2-5): Better for CPU-bound operations or rate-limited APIs
+1. **Concurrency Control**: Set appropriate `throttle:` limits to avoid overwhelming workers
+   - High throttle (20+): Suitable for I/O-bound operations (API calls, database queries)
+   - Low throttle (2-5): Better for CPU-bound operations or rate-limited APIs
 
 2. **Output Size**: Watch out for large output collections
    - With N×M combinations, the output array will have N×M elements
@@ -348,7 +358,8 @@ When implementing matrix processing:
    task :process_matrix,
         each: ->(_ctx) { combinations },
         timeout: 300.seconds,  # 5 minutes per iteration
-        enqueue: { concurrency: 5 } do |ctx|
+        enqueue: true,
+        throttle: 5 do |ctx|
      # ...
    end
    ```
@@ -358,7 +369,8 @@ When implementing matrix processing:
    task :process_matrix,
         each: ->(_ctx) { combinations },
         retry: { count: 3, strategy: :exponential },
-        enqueue: { concurrency: 5 } do |ctx|
+        enqueue: true,
+        throttle: 5 do |ctx|
      # ...
    end
    ```

data/guides/PRODUCTION_DEPLOYMENT.md

@@ -1,6 +1,6 @@
 # Production Deployment
 
-> ⚠️ **Early Stage (v0.4.0):** JobWorkflow is still in early development. While this section outlines potential deployment patterns, please thoroughly test in your specific environment and monitor for any issues before relying on JobWorkflow in critical production systems.
+> ⚠️ **Early Stage (v0.6.0):** JobWorkflow is still in early development. While this section outlines potential deployment patterns, please thoroughly test in your specific environment and monitor for any issues before relying on JobWorkflow in critical production systems.
 
 This section covers suggested settings and patterns for running JobWorkflow in production-like environments.
 

data/guides/README.md

@@ -1,6 +1,6 @@
 # JobWorkflow Guides
 
-> ⚠️ **Early Stage (v0.4.0):** JobWorkflow is in active development. APIs and features may change. The following guides provide patterns and examples for building workflows, but be aware that implementations may need adjustment as the library evolves.
+> ⚠️ **Early Stage (v0.6.0):** JobWorkflow is in active development. APIs and features may change. The following guides provide patterns and examples for building workflows, but be aware that implementations may need adjustment as the library evolves.
 
 Welcome to the JobWorkflow documentation! This directory contains comprehensive guides to help you build robust workflows with JobWorkflow.
 
@@ -127,6 +127,11 @@ Production deployment and operations:
   - Accessing arguments, outputs, and job status
   - Building dashboards and APIs
 
+- **[MONITORING_UI.md](MONITORING_UI.md)** - Monitoring UI for workflow execution
+  - Mounting the engine
+  - Navigating workflow definitions and executions
+  - Viewing DAG state, arguments, outputs, and fan-out progress
+
 - **[TESTING_STRATEGY.md](TESTING_STRATEGY.md)** - Testing your workflows
   - Unit testing individual tasks
   - Integration testing workflows

data/guides/THROTTLING.md

@@ -2,6 +2,8 @@
 
 JobWorkflow provides semaphore-based throttling to handle external API rate limits and protect shared resources. Throttling works across multiple jobs and workers, ensuring system-wide rate limiting.
 
+For async map tasks (`enqueue: true`), `throttle` is also the official way to cap concurrent sub-job execution. This limit is enforced at perform time by JobWorkflow semaphores, not by SolidQueue's ready/blocked dispatch-state controls.
+
 ## Task-Level Throttling
 
 ### Simple Integer Syntax (Recommended)
@@ -114,6 +116,28 @@ end
 # → Max 5 concurrent API calls at any time
 ```
 
+### Throttling Async Sub-Tasks
+
+When a map task runs as sub-jobs, combine `enqueue: true` with `throttle`:
+
+```ruby
+class AsyncBatchFetchJob < ApplicationJob
+  include JobWorkflow::DSL
+
+  argument :ids, "Array[Integer]"
+
+  task :fetch_all,
+       each: ->(ctx) { ctx.arguments.ids },
+       enqueue: true,
+       throttle: 5,
+       output: { data: "Hash" } do |ctx|
+    { data: RateLimitedAPI.fetch(ctx.each_value) }
+  end
+end
+```
+
+This keeps sub-job fan-out while ensuring only 5 iterations execute at the same time across workers.
+
 ## Runtime Throttling
 
 For fine-grained control within a task, use the `ctx.throttle` method to wrap specific code blocks. This method can only be called inside a task block; calling it outside will raise an error.

data/guides/WORKFLOW_STATUS_QUERY.md

@@ -2,6 +2,8 @@
 
 JobWorkflow provides a robust API for querying the execution status of workflows. This allows you to monitor running workflows, inspect their state, and build observability dashboards.
 
+`JobWorkflow::WorkflowStatus.find` and `find_by` are root workflow APIs. Pass the root workflow `job_id` only. Async sub-job IDs created by `enqueue: true` are intentionally excluded; inspect those via `JobWorkflow::JobStatus`.
+
 ## Basic Usage
 
 ### Finding a Workflow
@@ -16,6 +18,10 @@ return unless status
 
 # Check workflow status
 status.status  # => :pending, :running, :succeeded, or :failed
+
+# Sub-job IDs are excluded from WorkflowStatus
+JobWorkflow::WorkflowStatus.find_by(job_id: "sub-job-123")
+# => nil
 ```
 
 ### Status Check Methods
@@ -251,7 +257,7 @@ end
 
 ### NotFoundError
 
-When using `find`, a `JobWorkflow::WorkflowStatus::NotFoundError` is raised if the job is not found:
+When using `find`, a `JobWorkflow::WorkflowStatus::NotFoundError` is raised if the job is not found. The same applies if you pass a sub-job `job_id` instead of a root workflow `job_id`:
 
 ```ruby
 begin

data/lib/job_workflow/context.rb

@@ -2,6 +2,8 @@
 
 module JobWorkflow
   class Context # rubocop:disable Metrics/ClassLength
+    EACH_TASK_CURSOR_MARKER = "__job_workflow_each_cursor__"
+
     attr_reader :workflow #: Workflow
     attr_reader :arguments #: Arguments
     attr_reader :output #: Output
@@ -50,10 +52,12 @@ module JobWorkflow
     #     task_context: TaskContext,
     #     output: Output,
     #     job_status: JobStatus,
-    #     ?job: DSL?
+    #     ?job: _JobInterface?
     #   ) -> void
-    def initialize(workflow:, arguments:, task_context:, output:, job_status:, job: nil) # rubocop:disable Metrics/ParameterLists
-      raise "job does not match the provided workflow" if job&.then { |j| j.class._workflow != workflow }
+    def initialize(workflow:, arguments:, task_context:, output:, job_status:, job: nil) # rubocop:disable Metrics/ParameterLists, Metrics/AbcSize, Metrics/MethodLength
+      if job&.class.respond_to?(:_workflow) && job.class._workflow != workflow
+        raise "job does not match the provided workflow"
+      end
 
       self.job = job
       self.workflow = workflow
@@ -64,6 +68,8 @@ module JobWorkflow
       self.enabled_with_each_value = false
       self.throttle_index = 0
       self.skip_in_dry_run_index = 0
+      self.current_step = nil
+      self.current_cursor = nil
     end
 
     #:  () -> Hash[String, untyped]
@@ -77,12 +83,37 @@ module JobWorkflow
       self
     end
 
-    #:  (DSL) -> void
+    #:  () -> untyped
+    def cursor
+      return if current_step.nil?
+
+      current_cursor
+    end
+
+    #:  (untyped) -> void
+    def set_cursor!(value)
+      step = current_step || (raise "set_cursor! can be called only in task")
+
+      ActiveJob::Arguments.serialize([value])
+      self.current_cursor = value
+      step.set!(build_step_cursor(value))
+    end
+
+    #:  () -> void
+    def checkpoint!
+      step = current_step || (raise "checkpoint! can be called only in task")
+
+      return step.checkpoint! unless each_task?
+
+      step.set!(build_step_cursor(current_cursor))
+    end
+
+    #:  (_JobInterface) -> void
     def _job=(job)
       self.job = job
     end
 
-    #:  () -> DSL?
+    #:  () -> _JobInterface?
     def _job
       job
     end
@@ -220,6 +251,18 @@ module JobWorkflow
       task_context
     end
 
+    #:  (ActiveJob::Continuation::Step, ?cursor: untyped) { () -> void } -> void
+    def _with_current_step(step, cursor: nil)
+      previous_step = current_step
+      previous_cursor = current_cursor
+      self.current_step = step
+      self.current_cursor = cursor
+      yield
+    ensure
+      self.current_step = previous_step
+      self.current_cursor = previous_cursor
+    end
+
     #:  (TaskOutput) -> void
     def _add_task_output(task_output)
       output.add_task_output(task_output)
@@ -236,7 +279,7 @@ module JobWorkflow
 
     private
 
-    attr_accessor :job #: DSL?
+    attr_accessor :job #: _JobInterface?
     attr_writer :workflow #: Workflow
     attr_writer :arguments #: Arguments
     attr_writer :output #: Output
@@ -245,12 +288,31 @@ module JobWorkflow
     attr_accessor :enabled_with_each_value #: bool
     attr_accessor :throttle_index #: Integer
     attr_accessor :skip_in_dry_run_index #: Integer
+    attr_accessor :current_step #: ActiveJob::Continuation::Step?
+    attr_accessor :current_cursor #: untyped
 
     #:  () -> String
     def parent_job_id
       _task_context.parent_job_id || job_id
     end
 
+    #:  () -> bool
+    def each_task?
+      task_context.task.each?
+    end
+
+    #:  (untyped) -> untyped
+    def build_step_cursor(value)
+      return value unless each_task?
+      return task_context.index if value.nil?
+
+      {
+        EACH_TASK_CURSOR_MARKER => true,
+        "index" => task_context.index,
+        "cursor" => value
+      }
+    end
+
     #:  () -> Hash[String, untyped]
     def serialize_for_job
       {

data/lib/job_workflow/dsl.rb

@@ -128,7 +128,7 @@ module JobWorkflow
       #   ) { (untyped) -> void } -> void
       def task(
         task_name,
-        each: ->(_ctx) { [TaskContext::NULL_VALUE] },
+        each: Task::DEFAULT_EACH,
         enqueue: nil,
         retry: 0,
         output: {},
@@ -156,10 +156,6 @@ module JobWorkflow
           dry_run:
         )
         _workflow.add_task(new_task)
-        if new_task.enqueue.should_limits_concurrency? # rubocop:disable Style/GuardClause
-          concurrency = new_task.enqueue.concurrency #: Integer
-          workflow_concurrency(to: concurrency, key: :concurrency_key.to_proc)
-        end
       end
       # rubocop:enable Metrics/ParameterLists
 

data/lib/job_workflow/instrumentation/opentelemetry_subscriber.rb

@@ -18,7 +18,7 @@ module JobWorkflow
     #
     # @note This subscriber requires the opentelemetry-api gem to be installed.
     #   If not available, subscription will be silently skipped.
-    class OpenTelemetrySubscriber # rubocop:disable Metrics/ClassLength
+    class OpenTelemetrySubscriber
       module Attributes
         JOB_NAME = "#{NAMESPACE}.job.name".freeze #: String
         JOB_ID = "#{NAMESPACE}.job.id".freeze #: String