home / skills / makfly / superpowers-symfony / symfony-messenger

symfony-messenger skill

safe

This skill helps implement resilient Symfony Messenger workflows with idempotent handlers, configurable retries, and observability for reliable async

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

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-messenger
allowed-tools:
  - Read
  - Write
  - Edit
  - Bash
  - Glob
  - Grep
description: Implement resilient Symfony async workflows with idempotency, retries, and operational visibility. Use for symfony messenger tasks.
---

# Symfony Messenger (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 implements resilient asynchronous workflows for Symfony Messenger. It focuses on idempotent handlers, stable retry and failure transport policies, and operational visibility to make async processing predictable and debuggable. The skill produces concrete config changes and validation evidence for production readiness.

How this skill works

The skill inspects message contracts, handler implementations, routing, and Messenger retry/failure transport settings. It identifies at-least-once delivery risks, suggests idempotency patterns, and prescribes retry and dead-letter handling that match your delivery guarantees. Finally, it generates operational checks and evidence to validate replay and failure scenarios.

When to use it

You are building or refactoring async workflows with Symfony Messenger and Scheduler.
Handlers must be safe to process messages multiple times (at-least-once delivery).
You need a robust retry strategy and a failure (dead-letter) transport policy.
You want operational visibility into processing, retries, and poison messages.
You must validate replay and failure recovery before production rollout.

Best practices

Design message contracts with delivery semantics and required idempotency guarantees.
Keep handlers deterministic and make side effects explicit and reversible where possible.
Configure retries and failure transports based on failure types, not just counts.
Surface poison-message handling and alerting rather than silently dropping messages.
Add operational tests that simulate replay, transient errors, and permanent failures.

Example use cases

Processing payment events where duplicate handling must be prevented and recoverable.
Email sending pipelines that should retry transient SMTP failures and route permanent failures to a queue for inspection.
Data-sync jobs that require controlled replay after downstream outages with minimal duplication.
Background processing of webhooks where at-least-once delivery and visibility into poison messages are critical.

FAQ

Does this assume exactly-once delivery?

No. The skill assumes at-least-once delivery and focuses on idempotency and safe retries.

What evidence does it produce for operational validation?

Operational validation includes replay tests, configured retry/failure transport settings, and logs/metrics to show handling of transient and permanent failures.

Can it handle poison messages automatically?

It prescribes poison-message handling strategies and alerting; automated actions are configurable but should be aligned with your operational policies.