Circuit Breaker Testing Skill: Verify open, half-open, and recovery behavior under dependency failure

A circuit breaker is a state machine driven by evidence about dependency calls. A useful review checks what counts as a failure, when traffic is rejected locally, how recovery probes are limited, and what event closes or reopens the breaker.

Define the state contract

Before reviewing state names, collect the configured failure-count definition, rolling or consecutive window, threshold, open duration, half-open probe allowance, concurrency limit, and success or failure transitions. If any value is absent, keep it unknown instead of choosing a default.

State or transition	Behavior to verify from the contract
Closed	Which dependency outcomes count, and how are they added to the configured window?
Open	Are ordinary calls rejected locally, and which fallback is returned?
Half-open	How many recovery probes may run, and what happens to ordinary calls?
Reset/recovery transition	Which probe result and timing transition the breaker to closed or open? Use the project’s own name and rule.

Separate a real dependency request from a local rejection. Count each only as the configured policy says; a state label alone does not prove that the implementation followed the contract.

Trace one transition sequence

Build a request-identified timeline rather than a checklist of state names:

Event	State and count	Expected action	Evidence to retain
Dependency call returns a contract-defined failure	Closed; update the configured window	Keep closed until the documented trigger is met	Request ID, outcome, timestamp
Trigger is reached	Closed to open	Stop sending ordinary calls to the dependency	Transition event and local-rejection evidence
Open duration expires	Open to half-open	Admit only the allowed recovery probes	Probe identity, concurrency, timestamp
Probe succeeds or fails	Half-open to closed or open	Apply the documented transition and fallback	Probe result and resulting state

This table describes a review method, not an assumed project policy. Use the supplied threshold and event records. When logs are missing, label the transition expected or unverified rather than observed.

Worked example: regional timeout

For a breaker protecting a recommendation dependency, review a proposed regional timeout sequence. Confirm which calls contribute to the failure window, whether calls rejected while open affect that count, how many half-open probes may overlap, and whether a failed probe immediately reopens the breaker or follows another documented rule.

A validation proposal should run in an isolated environment with a stop condition, observe dependency calls separately from local rejections, and capture state and fallback evidence. Do not induce production failures or invent a threshold for the example.

Keep the state label separate from request behavior. Illustrative example: if a dashboard shows Open but there is no transition event, request identity, or dependency-call record, it proves only that the view displayed a state; it does not show that ordinary calls were rejected locally. If the supplied policy requires rejection while open and ordinary calls still reach the dependency in the same window, retain request-level evidence and review the implementation. Without a run record, the behavior remains unverified.

Findings and boundaries

Use CBR-## for an unclear transition or protection rule. Include the state and request, source, trigger, pre-state and count, action, post-state, fallback, evidence status, impact, owner role, close condition, and validation method. Include concurrency and time-boundary cases where the supplied contract makes them relevant.

This Skill reviews circuit-breaker behavior only. Use Dependency Failure Testing: https://inaodeng.com/en/qaskills/dependency-failure-testing/ for the wider caller/dependency side-effect matrix, Retry Testing: https://inaodeng.com/en/qaskills/retry-testing/ for retry interaction, and Recovery Testing: https://inaodeng.com/en/qaskills/recovery-testing/ for broader recovery outcomes.

Do not infer failure thresholds, recovery duration, or production behavior. A configured state and a designed test are not evidence that the breaker transitioned at runtime.

Install and invoke

Install the individual Skill:

npx skills add https://github.com/naodeng/awesome-qa-skills/tree/main/skills/en --skill circuit-breaker-testing

Invoke circuit-breaker-testing with the state policy, failure-count rules, probe limits, fallback contract, and request-level evidence. Start with a redacted trace:

Review this redacted circuit-breaker event trace with circuit-breaker-testing.
Contract: [failure count, window, threshold, open duration, half-open probe allowance/concurrency, fallback, and transitions]
Trace: [request IDs, timestamps, dependency outcomes, local rejections, probe outcomes, and state events]
Scope: [environment, version, and calls included or excluded]
Return a per-event pre-state/count/action/post-state/fallback table and candidate CBR-## findings. Separate expected from observed behavior. Do not invent thresholds or present static review as runtime evidence.

FAQ

Does an Open label in monitoring prove that ordinary calls were rejected locally? No. Compare request identities, dependency-call records, and local-rejection evidence in the same time window.

Will the Skill inject a failure into the target dependency? No. It reviews supplied materials and prepares isolated validation proposals; live fault injection is outside its scope.

Source

Read the Circuit-Breaker Testing prompt: https://github.com/naodeng/awesome-qa-skills/tree/main/skills/en/testing-types/circuit-breaker-testing/prompts/circuit-breaker-testing.md before use. It defines the CBR-## finding contract and the per-event pre-state/count/action/post-state/fallback table.