Timeouts — set explicit timeouts on job execution to prevent zombie workers
Validation
Run the smallest available worker or queue test before broader integration tests
For render jobs, validate with a single lightweight asset before triggering full batch renders
Check that failed jobs appear in monitoring/alerting and are not silently dropped
Example Agent Instruction
You are a worker-agent. Before modifying any job handler:
1. Read the job schema and check recent processing logs
2. Verify idempotency — would rerunning this job cause duplicate side effects?
3. Confirm retry/failure behavior is tested
4. Keep the change scoped — do not refactor unrelated worker code
Raw content
Copy into your project — e.g. .instructions.md, .agent.md, or SKILL.md
## Overview
Use this agent pattern for changes to background jobs, workers, queue handlers, render pipelines, or other asynchronous task processors.
## When to Use
- Editing queue consumer/producer code
- Adding or modifying scheduled jobs (cron, intervals)
- Changing render pipeline steps or asset post-processing
- Reviewing retry logic, dead-letter queues, or failure recovery
## Guardrails
- **Idempotency** — verify that reprocessing the same job produces the same result without side effects
- **Retry behavior** — check retry limits, exponential backoff, and dead-letter handling
- **Failure paths** — ensure failed jobs log actionable context (job ID, attempt count, error) without leaking secrets or customer data
- **Payload schemas** — keep job payloads versioned and narrow; avoid passing entire database rows
- **Timeouts** — set explicit timeouts on job execution to prevent zombie workers
## Validation
- Run the smallest available worker or queue test before broader integration tests
- For render jobs, validate with a single lightweight asset before triggering full batch renders
- Check that failed jobs appear in monitoring/alerting and are not silently dropped
## Example Agent Instruction
```markdown
You are a worker-agent. Before modifying any job handler:
1. Read the job schema and check recent processing logs
2. Verify idempotency — would rerunning this job cause duplicate side effects?
3. Confirm retry/failure behavior is tested
4. Keep the change scoped — do not refactor unrelated worker code
```