← Business Systems Specialist Collection adatlapja
Nézd meg, miben segít
Újrapróbálás és kompenzáció
Tartós eredménnyel és korlátos ismétléssel kezeli a hibás lépést és bizonytalan külső hatást.
retries-compensation
Ezt a skillt használó csapattagok
Mikor hasznos?
Akkor használd, ha korábbi sikeres műveletek után hibázhat a folyamat.
Miben segít neked?
- Csak a hibás lépést ismétli stabil azonosítóval.
- Elkülöníti az átmeneti hibát, elutasítást és ismeretlen kimenetet.
- Üzleti kompenzációt és látható kézi helyreállást tervez.
Például ezt kérheted
Tervezz helyreállást készletfoglalás utáni sikertelen aktiválásra, bizonytalan fizetős művelet ismétlése előtt szolgáltatói ellenőrzéssel. Igazolt foglalás és bizonytalan terhelés után hibázzon a létrehozás. Csak biztonságosan feloldható foglalást engedj el, a terhelést ismétlés előtt egyeztesd.
Részletes dokumentáció
Itt a skill eredeti útmutatóját, példáit és ellenőrzési szempontjait olvashatod az eredeti nyelven.
Összecsukás
Retries & Compensation
Use this skill when designing error handling, backoff retry policies, idempotency guarantees, manual recovery, and Saga compensations in workflows.
Step-Scoped Retries & Idempotency (Helland & Hohpe)
- Retry the Failing Step, Never the Whole Workflow from Scratch:
- When step $S_k$ fails after steps $S_1 \dots S_{k-1}$ succeeded, checkpointed upstream results remain intact. Retry only $S_k$ according to its step-level policy (
maxAttempts, initial delay, exponential backoff, jitter).
- When step $S_k$ fails after steps $S_1 \dots S_{k-1}$ succeeded, checkpointed upstream results remain intact. Retry only $S_k$ according to its step-level policy (
- Deterministic Idempotency Keys for External Side Effects:
- Never promise "exactly-once" external execution without an idempotency mechanism.
- Derive a deterministic idempotency key (
hash(tenantId, runId, stepExecutionId)) that stays identical across retry attempts of the same step execution, and pass it to downstream APIs (payments, emails, ticket creation, order placement).
- Separate Retryable vs. Non-Retryable Failures:
- Retryable: Transient network timeouts,
429 Too Many Requests,502/503/504gateway errors. - Non-Retryable (Fail Immediately): Validation errors (
400/422), permission denials (401/403), missing resources (404), or business rule rejections.
- Retryable: Transient network timeouts,
- Surface Uncertain External Outcomes Explicitly:
- If a non-idempotent external call times out after the request was sent, do not blindly re-send a second charge or message. Mark the attempt as
uncertain_side_effector query the remote provider's status before retrying or escalating to operator review.
- If a non-idempotent external call times out after the request was sent, do not blindly re-send a second charge or message. Mark the attempt as
Saga Compensation & Partial Failure Recovery
- Compensating Steps Are Forward Business Actions, Not Magic Time Travel:
- When a multi-step workflow fails at step 4 after steps 1–3 committed external changes (e.g., reserved stock, created invoice draft, provisioned user), execute explicit compensating steps in reverse topological order (
ReleaseStock,VoidDraftInvoice,DeprovisionUser). - Record compensation status (
compensating$\to$compensated|compensation_failed) distinctly in the run history, and make compensating handlers idempotent and retryable themselves.
- When a multi-step workflow fails at step 4 after steps 1–3 committed external changes (e.g., reserved stock, created invoice draft, provisioned user), execute explicit compensating steps in reverse topological order (
- Controlled Operator Replay (
Retry from Failed Step):- Allow authorized operators to retry a failed step or resume a paused run from its last durable checkpoint with full audit logging.
Checklist
- Are retries scoped to the individual failing step using a stable per-step
idempotencyKeyrather than re-running completed prior steps? - Are non-retryable
4xx/validation errors separated from transient5xx/429errors? - Are post-dispatch timeouts on non-idempotent external calls flagged or reconciled before retrying?
- Are Saga compensations modeled as explicit, idempotent reverse steps with their own tracked execution status?
Csomagban lévő fájlok 1
SKILL.md
