- Home
- Skills
- Makfly
- Superpowers Symfony
- Symfony Messenger
symfony-messenger_skill
- Shell
69
GitHub Stars
2
Bundled Files
2 months ago
Catalog Refreshed
4 months ago
First Indexed
Readme & install
Copy the install command, review bundled files from the catalogue, and read any extended description pulled from the listing source.
Installation
Preview and clipboard use veilstrat where the catalogue uses aiagentskills.
npx veilstrat add skill makfly/superpowers-symfony --skill symfony-messenger- reference.md662 B
- SKILL.md1.1 KB
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
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.