Skip to main content

Basic Usage

Signature

Type Safety

The @Job decorator enforces at compile time:
  • The decorated class must extend JobContext
  • The execute() parameter must exactly match the inputSchema type
  • The execute() return type must match the outputSchema type
  • Both inputSchema and outputSchema are required for Jobs

Configuration Options

Required Properties

Optional Properties

RetryConfig

Permission

Examples

Simple Job

Job with Retry

Job with Permissions

Function-Based Alternative

For simpler jobs, use the job() function:
The handler’s ctx is the run’s JobContext, the object a class job reaches as this, so ctx.log(), ctx.progress(), ctx.get() and ctx.attempt behave as they do in a class. Up to 1.9.0 log() and progress() were protected, so only a JobContext class could call them.

Context Methods

The JobContext base class provides:

Dependency Injection

Logging and Progress

Error Handling

Hooks

Each attempt of a job runs the hookable jobs:execute-job flow (JobHook), so plugins and providers can hook every run, retry and workflow step of a job. A job class can declare hooks for that flow too: instance methods from createJobContext on, static methods for the earlier stages.
See Jobs: Hooks for the stages and how retries, background runs and workflow steps run them.

JobContext

Context class details

JobRegistry

Job registry API

Jobs Guide

Jobs documentation

@Workflow

Define workflows