home / skills / makfly / superpowers-symfony / symfony-scheduler

symfony-scheduler skill

safe

This skill helps implement resilient Symfony async workflows with idempotent handlers, retries, and observability for scheduler tasks.

npx playbooks add skill makfly/superpowers-symfony --skill symfony-scheduler

Review the files below or copy the command above to add this skill to your agents.

Files (2)

SKILL.md

1.1 KB

---

name: symfony:symfony-scheduler
allowed-tools:
  - Read
  - Write
  - Edit
  - Bash
  - Glob
  - Grep
description: Implement resilient Symfony async workflows with idempotency, retries, and operational visibility. Use for symfony scheduler tasks.
---

# Symfony Scheduler (Symfony)

## Use when
- Implementing asynchronous workflows with Messenger/Scheduler/Cache.
- Stabilizing retries and failure transports.

## Default workflow
1. Define async contract and delivery semantics.
2. Implement idempotent handlers and routing strategy.
2. Configure retries, failure transport, and observability.
2. Validate success/failure replay scenarios.

## Guardrails
- Assume at-least-once delivery, not exactly-once.
- Keep handlers deterministic and side-effect aware.
- Surface poison-message handling strategy.

## Progressive disclosure
- Use this file for execution posture and risk controls.
- Open references when deep implementation details are needed.

## Output contract
- Async config/handlers updated.
- Retry/failure policy decisions.
- Operational validation evidence.

## References
- `reference.md`
- `docs/complexity-tiers.md`

Overview

This skill helps implement resilient asynchronous workflows for Symfony Scheduler, focusing on idempotency, retries, and operational visibility. It provides guidance to update async contracts, handlers, and retry/failure policies to operate reliably under at-least-once delivery. The result is a hardened scheduler setup with clear operational controls and validation steps.

How this skill works

The skill inspects your async contract, delivery semantics, and handler implementations to identify non-determinism and side effects. It recommends idempotency patterns, routing and retry configuration for Symfony Messenger/Scheduler, and a failure transport strategy. It also defines observable signals and validation steps to prove safe replay and recovery.

When to use it

Building or refactoring Symfony async tasks backed by Messenger/Scheduler
Stabilizing systems that experience duplicate deliveries or flaky retries
Defining operational controls for scheduled jobs and failure transports
Preparing systems for safe replays or disaster recovery testing

Best practices

Assume at-least-once delivery; design handlers to tolerate duplicates and partial runs
Make handlers idempotent by using dedup keys, versioned state, or transactional checkpoints
Keep handlers deterministic: avoid non-repeatable external calls without compensation
Centralize retry and failure transport policies; treat poison messages explicitly
Add observability: structured logs, metrics for retries/poisons, and replay audit trails

Example use cases

Convert scheduler tasks that mutate external systems into idempotent command handlers with dedup keys
Configure Messenger retry and failure transport with clear escalation paths for human review
Validate replay scenarios by running recorded inputs against handlers in a sandbox and asserting idempotent outcomes
Instrument scheduler jobs to emit retry and failure metrics and integrate with alerting
Implement a poison-message handler that quarantines and annotates failed payloads for manual triage

FAQ

Do I need exactly-once semantics?

No. This skill assumes at-least-once delivery and focuses on idempotency and safe retries rather than trying to enforce exactly-once at the transport level.

How do I validate that replays are safe?

Capture representative inputs and run them against handlers in an isolated environment. Verify state is unchanged for retried payloads or that compensating actions are applied deterministically.