A dependency timeout does not tell you whether a write happened. The caller may have stopped waiting after a provider committed the request, leaving a retry capable of creating a duplicate reservation or payment. Dependency Failure Testing keeps that uncertainty and its business side effects visible.
What this Skill examines
Use this Skill to review dependency-failure classification, isolation, degradation, fallback, and recovery preparation across services, databases, queues, and external providers. It does not inject faults, access live dependencies, or claim that a recovery test ran.
Start with the dependency contract
Record the caller and dependency, synchronous or asynchronous interaction, timeout and retry rules, fallback behavior, and business or data invariants. Then identify which source supports each rule and what evidence is missing or stale.
| Failure shape | Questions the review must answer |
|---|---|
| Unreachable or error response | Was the request rejected before any side effect? What evidence supports that? |
| Timeout or slow response | Could the dependency have accepted or committed the operation after the caller stopped waiting? |
| Partial success | Which records, messages, or downstream calls may already have changed? |
| Async delay, duplicate, or reordering | What do pending state and acknowledgment mean? How is replay made safe? |
| Recovery | How are backlog, local state, and dependency state reconciled or compensated? |
Do not infer “not committed” from a timeout or HTTP 500. Join the caller record, dependency outcome, retry, and message or database side effects by request or message ID and timeline.
Worked example: inventory reservation
Assume a synchronous inventory request times out after it is sent, and the caller considers a retry. The design review should ask whether the dependency received the first request, whether the operation has an idempotency key, what state can be queried, and how a duplicate reservation would be detected or compensated.
The expected contract might distinguish a confirmed rejection from an unknown outcome. In the unknown case, the caller should reconcile before retrying a non-idempotent write. This is a design example only; it supplies no real provider behavior or execution evidence.
For an asynchronous queue, review delayed delivery, duplicate messages, ordering, and lost acknowledgment separately. A message still pending is not the same state as a failed operation, and a successful acknowledgment is not automatically proof that every business side effect completed.
How to interpret example evidence
These are illustrative outcomes, not claims about a provider’s actual behavior.
| Supplied observation | Bounded interpretation | Next action |
|---|---|---|
| The caller timed out and the dependency lookup still says unknown | The write outcome is unresolved; a timeout is not a rejection | Reconcile by request identity and do not blindly retry a non-idempotent write |
| An authoritative dependency record says the request was rejected before side effects | This supports rejection only for that request and evidence scope | Retain the lookup result, request ID, and timestamp, then review retry behavior |
| Multiple reservation records share one business intent | This suggests a duplicate side effect, but the impact needs source-record review | Join the original request, retry, and ledger; let the owner decide compensation or further validation |
Build a reviewable finding
Use DPF-## for each risk. Record the caller and dependency, interaction mode, failure trigger, side-effect window, invariant at risk, source and evidence state, expected result, priority, owner role, close condition, validation method, and stop condition. The scenario should distinguish synchronous rejection, asynchronous pending work, and unknown commit.
A useful validation proposal names an isolated environment, synthetic or masked data, the request identity to trace, the expected state reconciliation, and the point at which the exercise must stop. Do not run the fault injection as part of this design review.
Boundaries and related Skills
Keep design facts, evidence-backed inferences, candidate recommendations, and Human decisions separate. Leave unsupported thresholds and provider behavior open for confirmation. Retry Testing: https://inaodeng.com/en/qaskills/retry-testing/ examines retry policy; Recovery Testing: https://inaodeng.com/en/qaskills/recovery-testing/ checks restoration to a safe state; Circuit Breaker Testing: https://inaodeng.com/en/qaskills/circuit-breaker-testing/ focuses on breaker states and probe traffic.
Install and invoke
Install the individual Skill:
npx skills add https://github.com/naodeng/awesome-qa-skills/tree/main/skills/en —skill dependency-failure-testing
Invoke dependency-failure-testing with the dependency contract, caller and dependency states, interaction mode, evidence, and business invariants. Start with a redacted scenario:
Review this dependency-failure scenario with dependency-failure-testing.
Contract: [caller, dependency, sync/async mode, timeout/retry/fallback rules, business invariants]
Evidence: [request or message IDs, caller state, dependency state, retries, message/database side effects]
Scope: [environment, version, operations included or excluded]
Separate confirmed rejection, asynchronous pending work, and unknown commit. List candidate DPF-## findings, evidence gaps, and the smallest isolated validation steps. Do not treat a timeout or HTTP 500 as proof that no write occurred, and do not claim that a fault was injected.FAQ
Does a caller timeout or HTTP 500 show that a write did not happen? No. Reconcile dependency state and side effects by request or message ID; do not blindly retry a non-idempotent write when its result is unknown.
Will the Skill inject a fault into a live dependency? No. It reviews supplied material and prepares an isolated validation plan; fault injection needs separate authorization and a safe test environment.
Source
Read the Dependency-Failure Testing prompt: https://github.com/naodeng/awesome-qa-skills/tree/main/skills/en/testing-types/dependency-failure-testing/prompts/dependency-failure-testing.md before use. It defines the DPF-## output contract and failure-mode/caller/dependency/side-effect matrix.