Trigger.dev Configuration

Relevant source files

The following files were used as context for generating this wiki page:

• trigger.config.ts
• package.json
• AGENTS.md
• src/tasks/sendPulsesTask.ts
• src/tasks/createContentTask.ts
• src/tasks/customerPromptTask.ts
• README.md

Trigger.dev serves as the primary background task orchestration engine for the Recoup project. It manages long-running workflows, scheduled integrations, and resource-intensive media generation pipelines that would otherwise exceed the capabilities of standard serverless functions.

The system utilizes Trigger.dev v4 SDK patterns, specifically leveraging task(), schemaTask(), and schedules.task() to define different types of background workloads. These tasks integrate with external APIs like Recoup Chat, Recoup API, and various social media platforms to automate artist-related operations.

Sources: AGENTS.md:15-20, README.md:1-5

Global SDK Configuration

The project centralizes its Trigger.dev behavior within trigger.config.ts. This configuration defines the runtime environment, compute resource allocation, and build-time extensions required for media processing.

Hardware and Runtime

Tasks are configured to run in a Node.js runtime environment. The project uses the micro machine preset by default but allows individual tasks to override this setting (e.g., media generation uses medium-1x). A global maxDuration of 3600 seconds (1 hour) is enforced to prevent runaway processes.

Sources: trigger.config.ts:4-12, src/tasks/createContentTask.ts:50-55

Build Extensions

The build process includes specific core extensions to support specialized task logic:

• FFmpeg: Bundled via ffmpeg() to support video rendering and audio manipulation in the content creation pipeline.
• Additional Files: Uses additionalFiles() to bundle template assets (JSON guides, PNG/JPG images) from src/content/templates/**/* into the worker environment.

Sources: trigger.config.ts:24-37

Retry Strategy

A robust retry mechanism is enabled even in development mode. The default policy includes:

Property	Value	Description
maxAttempts	3	Maximum number of execution attempts.
minTimeoutInMs	1000	Minimum delay between retries.
maxTimeoutInMs	10000	Maximum delay between retries.
factor	2	Exponential backoff factor.
randomize	true	Adds jitter to retry timing.

Sources: trigger.config.ts:13-22

Task Architecture and Implementation

The project categorizes tasks based on their trigger mechanism and resource requirements. All tasks are located within the src/tasks directory as specified in the configuration.

Logic Flow for Scheduled Pulse Generation

The sendPulsesTask demonstrates a scheduled orchestration pattern where a parent task coordinates multiple sub-tasks.

This flow illustrates the usage of batchTriggerAndWait to handle concurrent processing of multiple accounts while maintaining individual execution isolation.

Sources: src/tasks/sendPulsesTask.ts:117-156, trigger.config.ts:23

Specialized Content Pipeline

Resource-intensive tasks, such as create-content, utilize schemaTask for strict Zod validation of input payloads.

The createContentTask explicitly overrides the default machine configuration to medium-1x and sets a custom maxDuration of 30 minutes to accommodate AI generation and FFmpeg rendering.

Sources: src/tasks/createContentTask.ts:48-55, src/tasks/createContentTask.ts:60-120

CLI and Operations

The project utilizes the pnpm package manager for Trigger.dev operations. Configuration and deployment are handled through standard scripts.

Command	Action
pnpm dev	Starts the Trigger.dev development mode (trigger.dev@4.3.3 dev).
pnpm run deploy:trigger-prod	Deploys tasks to the production environment using the trigger deploy CLI command.
pnpm install	Ensures required dependencies like @trigger.dev/sdk and @trigger.dev/build are present.

Sources: package.json:2-10, AGENTS.md:23-27

Development Patterns

The repository enforces strict architectural principles for Trigger.dev development to ensure reliability and maintainability.

• SDK Version: Strictly locked to v4 (4.3.3). Deprecated patterns like client.defineJob are explicitly forbidden.
• Wait Patterns: triggerAndWait() is the standard for child task orchestration. Developers are instructed never to wrap triggerAndWait or wait calls in Promise.all to avoid blocking the event loop incorrectly.
• Validation: Zod is required for all task payloads via schemaTask.
• Logging: The @trigger.dev/sdk/v3 logger is the mandatory logging utility for all task executions.
• Metadata: Tasks frequently use metadata.set or metadata.append to track step progress, making the execution state visible in the Trigger.dev dashboard.

Sources: AGENTS.md:37-45, src/sandboxes/logStep.ts:1-20, package.json:11-20

Conclusion

The Trigger.dev configuration for the Recoup project is designed to handle complex, asynchronous music industry workflows. By combining global environment settings in trigger.config.ts with granular task-level overrides and strict development patterns, the system provides a scalable foundation for AI-driven content generation and automated artist management.