home / skills / makfly / superpowers-symfony / symfony-cache

symfony-cache skill

safe

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

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

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

# Symfony Cache (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 Symfony asynchronous workflows that use the cache for coordination, idempotency, and operational visibility. It focuses on stabilizing retries, handling failures, and providing clear execution posture for Messenger and Scheduler jobs. The output is actionable configuration updates and validation artifacts to reduce flakiness in async processing.

How this skill works

The skill inspects async contracts, handler implementations, and cache usage to enforce idempotency and deterministic behavior. It recommends routing, retry, and failure-transport configurations and surfaces poison-message and replay scenarios. Finally, it produces operational validation steps and evidence for observability and incident handling.

When to use it

Building Messenger or Scheduler background jobs that interact with shared resources
You need at-least-once delivery guarantees with safe retries
Stabilizing flaky async tasks that cause duplicate side effects
Introducing failure transport and replayability into existing async flows
Adding operational visibility and evidence for async execution and retries

Best practices

Design handlers to be idempotent and deterministic; prefer cache-based locks or dedup keys for safe retries
Assume at-least-once delivery; do not rely on exactly-once semantics
Centralize retry and failure-transport policies in configuration, not ad-hoc code
Use cache TTLs and explicit keys to limit replays and control backpressure
Surface poison-message handling and alerting so bad payloads are quarantined quickly
Document expected delivery semantics and validation steps for operational teams

Example use cases

A Messenger job writes to an external API; use cache-based dedup keys to make calls idempotent and add a failure transport for manual replay
Scheduler-triggered cleanup tasks that must not run concurrently; use cache locks and retry policies to enforce single execution
High-throughput event handlers where transient failures require retries; configure exponential backoff and observable retry metrics
Migration of legacy async consumers: add idempotency markers in cache and validate replay scenarios before cutover

FAQ

Does this approach guarantee exactly-once processing?

No. It assumes at-least-once delivery and uses idempotency and coordination patterns to make repeated deliveries safe.

What operational evidence is produced?

Updated async config, handler changes, retry/failure policy decisions, and validation artifacts such as replay test results and observability checks.