Skip to content

Latest commit

 

History

History
76 lines (58 loc) · 3.75 KB

File metadata and controls

76 lines (58 loc) · 3.75 KB

Jobs

Jobs are background tasks that run automatically when events occur. Snaapi includes a built-in webhook delivery job. You can monitor job executions and configure retry behavior through the admin console.

Job Definitions

A job connects an event pattern to a processor function:

Field Type Description
id string UUID identifier
name string Display name
description string Human-readable description
eventPattern string Pattern to match events (e.g., posts.*, *)
processorName string Name of the registered processor
enabled boolean Whether the job is active
retryConfig retry settings or null Custom retry configuration
createdAt string ISO 8601 creation timestamp
updatedAt string ISO 8601 last-updated timestamp

Built-in Processors

Processor Name Description
webhook-delivery Delivers events to registered webhook endpoints

Execution Tracking

When an event matches a job's event pattern, a JobExecution record is created to track processing:

Field Type Description
id string Execution UUID
jobId string Parent job ID
eventId string Associated event ID
status string pending, running, completed, or failed
attemptNumber number Current attempt number
startedAt string or null Timestamp when execution started
completedAt string or null Timestamp when execution completed
error string or null Error message (if failed)
result object or null Result data returned by the processor
nextRetryAt string or null Scheduled time for next retry
createdAt string ISO 8601 creation timestamp

Execution Status Transitions

pending → running → completed
                  → failed → pending (retry)

Retry Configuration

Jobs use exponential backoff for failed executions. Defaults are used when no custom retryConfig is provided:

Property Default
maxAttempts 3
initialDelayMs 1,000 ms
backoffMultiplier 2
maxDelayMs 60,000 ms

The delay between retries is calculated as:

delay = min(initialDelayMs * backoffMultiplier ^ (attempt - 1), maxDelayMs)

On failure, the execution remains in pending status with a calculated nextRetryAt timestamp until all retry attempts are exhausted, at which point it transitions to failed.