condition-based-waiting

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Condition-Based Waiting Skill

Condition-Based Waiting Skill（基于条件的等待技能）

Operator Context

操作符上下文

This skill operates as an operator for wait and retry implementations, configuring Claude's behavior for robust condition-based polling. It implements the Pattern Selection architectural approach -- identify wait scenario, select pattern, implement with safety bounds, verify behavior.

本技能作为等待与重试实现的操作符，配置Claude的行为以实现健壮的基于条件的轮询。它采用模式选择架构方法——识别等待场景、选择模式、结合安全边界实现、验证行为。

Hardcoded Behaviors (Always Apply)

硬编码行为（始终适用）

CLAUDE.md Compliance: Read and follow repository CLAUDE.md before implementation
Over-Engineering Prevention: Only implement the pattern directly needed. Don't add circuit breakers when simple retries suffice. Don't add health checks when a single poll works.
Always Include Timeout: Every wait loop MUST have a maximum timeout to prevent infinite hangs
Always Include Max Retries: Every retry loop MUST have a maximum retry count
Always Add Jitter: Exponential backoff MUST include random jitter to prevent thundering herd
Never Busy Wait: Minimum 10ms between polls for local operations, 100ms for external services
Descriptive Timeout Errors: Timeout messages MUST include what was waited for and last observed state

遵循CLAUDE.md规范：实现前请阅读并遵循仓库中的CLAUDE.md
防止过度设计：仅实现直接需要的模式。当简单重试足够时，不要添加circuit breakers；当单次轮询可行时，不要添加health checks。
必须包含超时：每个等待循环都必须设置最大超时时间，以防止无限挂起
必须包含最大重试次数：每个重试循环都必须设置最大重试次数
必须添加抖动：exponential backoff必须包含随机抖动，以避免“惊群效应”
禁止忙等：本地操作的轮询间隔至少10ms，外部服务至少100ms
描述性超时错误：超时消息必须包含等待的对象以及最后观测到的状态

Default Behaviors (ON unless disabled)

默认行为（默认启用，可禁用）

Progress Reporting: Report wait progress with timeout values and retry counts
Cleanup on Timeout: Cancel pending operations when timeout expires
Logging on Failure: Log each retry attempt with failure reason and attempt number
Related Pattern Check: Search codebase for existing wait/retry patterns to maintain consistency
Minimum Poll Interval Enforcement: Enforce floor on polling frequency based on target type
Monotonic Clock Usage: Use
```
time.monotonic()
```
(not
```
time.time()
```
) for elapsed time to avoid clock drift
Error Classification: Separate transient from permanent errors before implementing retries

进度报告：报告等待进度，包含超时值和重试次数
超时清理：超时到期时取消待处理操作
失败日志：记录每次重试尝试，包含失败原因和尝试次数
关联模式检查：搜索代码库中已有的等待/重试模式，以保持一致性
最小轮询间隔强制：根据目标类型强制设置轮询频率下限
使用单调时钟：使用
```
time.monotonic()
```
（而非
```
time.time()
```
）计算已用时间，避免时钟漂移
错误分类：在实现重试前区分临时错误与永久错误

Optional Behaviors (OFF unless enabled)

可选行为（默认禁用，可启用）

Progress Callbacks: Report progress during long waits via user-provided callback
Metrics Collection: Track retry counts, wait times, and failure rates for monitoring
Fallback Values: Return cached/default values when retries exhausted
Dead Letter Logging: Record permanently failed operations for manual review

进度回调：通过用户提供的回调函数报告长等待过程中的进度
指标收集：跟踪重试次数、等待时间和失败率，用于监控
回退值：重试耗尽时返回缓存/默认值
死信日志：记录永久失败的操作，供人工审核

What This Skill CAN Do

本技能可实现的功能

Implement condition-based polling with bounded timeouts
Add exponential backoff with jitter to retry logic
Handle API rate limits with Retry-After header support
Wait for services to become healthy (TCP, HTTP, command)
Implement circuit breaker patterns for cascade failure prevention
Provide both Python and Bash implementations

实现带有限定时超时的基于条件的轮询
为重试逻辑添加带抖动的exponential backoff
支持Retry-After头的API限流恢复
等待服务进入健康状态（TCP、HTTP、命令行）
实现circuit breaker模式以防止级联故障
提供Python和Bash两种实现

What This Skill CANNOT Do

本技能无法实现的功能

Fix underlying service issues (only handles transient failures)
Guarantee eventual success (some operations permanently fail)
Replace proper async/await patterns for event-driven code
Handle distributed coordination (use distributed locks instead)
Provide real-time guarantees (polling has inherent latency)

修复底层服务问题（仅处理临时故障）
保证最终成功（部分操作会永久失败）
替代事件驱动代码中的异步/等待模式
处理分布式协调（请使用分布式锁）
提供实时保证（轮询存在固有延迟）

Quick Reference

快速参考

Pattern	Use When	Key Safety Bound
Simple Poll	Wait for condition to become true	Timeout + min poll interval
Exponential Backoff	Retry with increasing delays	Max retries + jitter + delay cap
Rate Limit Recovery	API returns 429	Retry-After header + default fallback
Health Check	Wait for service(s) to be ready	All-pass requirement + per-check status
Circuit Breaker	Prevent cascade failures	Failure threshold + recovery timeout

模式	适用场景	核心安全边界
Simple Poll	等待条件变为真	超时时间 + 最小轮询间隔
Exponential Backoff	重试失败操作	最大重试次数 + 抖动 + 延迟上限
Rate Limit Recovery	API返回429错误	Retry-After头 + 默认回退
Health Check	等待服务启动完成	全通过要求 + 单检查状态
Circuit Breaker	防止级联故障	失败阈值 + 恢复超时

Instructions

操作步骤

Phase 1: IDENTIFY WAIT PATTERN

阶段1：识别等待模式

Goal: Select the correct pattern for the use case.

Decision Tree:

1. Waiting for a condition to become true?
   YES -> Simple Polling (Phase 2)
   NO  -> Continue

2. Retrying a failing operation?
   YES -> Rate-limited (429)?
         YES -> Rate Limit Recovery (Phase 4)
         NO  -> Exponential Backoff (Phase 3)
   NO  -> Continue

3. Waiting for a service to start?
   YES -> Health Check Waiting (Phase 5)
   NO  -> Continue

4. Service frequently failing, need fast-fail?
   YES -> Circuit Breaker (Phase 6)
   NO  -> Simple Poll or Backoff

Gate: Pattern selected with rationale. Proceed only when gate passes.

目标：为使用场景选择正确的模式。

决策树：

1. 是否在等待条件变为真？
   是 -> Simple Polling（阶段2）
   否 -> 继续

2. 是否在重试失败操作？
   是 -> 是否触发限流（429）？
         是 -> Rate Limit Recovery（阶段4）
         否 -> Exponential Backoff（阶段3）
   否 -> 继续

3. 是否在等待服务启动？
   是 -> Health Check Waiting（阶段5）
   否 -> 继续

4. 服务频繁失败，需要快速失败？
   是 -> Circuit Breaker（阶段6）
   否 -> Simple Poll或Backoff

检查点：已选择模式并说明理由。仅当检查点通过后才可继续。

Phase 2: SIMPLE POLLING

阶段2：Simple Polling（简单轮询）

Goal: Wait for a condition to become true with bounded timeout.

Step 1: Define the condition function (returns truthy when ready)

Step 2: Set timeout and poll interval

Local operations: 10-100ms poll interval, 30s timeout
External services: 1-5s poll interval, 120s timeout

Step 3: Implement with safety bounds

python

undefined

目标：在有限超时内等待条件变为真。

步骤1：定义条件函数（条件满足时返回真值）

步骤2：设置超时时间和轮询间隔

本地操作：10-100ms轮询间隔，30s超时
外部服务：1-5s轮询间隔，120s超时

步骤3：结合安全边界实现

python

undefined

Core pattern (full implementation in references/implementation-patterns.md)

核心模式（完整实现见references/implementation-patterns.md）

start = time.monotonic() deadline = start + timeout_seconds while time.monotonic() < deadline: result = condition() if result: return result time.sleep(poll_interval) raise TimeoutError(f"Timeout waiting for: {description}")


**Step 4**: Test with both success and timeout scenarios

**Gate**: Polling works for success case AND raises TimeoutError appropriately. Proceed only when gate passes.


**步骤4**：测试成功和超时两种场景

**检查点**：轮询在成功场景下正常工作，且在超时场景下正确抛出TimeoutError。仅当检查点通过后才可继续。

Phase 3: EXPONENTIAL BACKOFF

阶段3：Exponential Backoff（指数退避）

Goal: Retry failing operations with increasing delays and jitter.

Step 1: Identify retryable vs non-retryable errors

Retryable: 408, 429, 500, 502, 503, 504, network timeouts, connection refused
Non-retryable: 400, 401, 403, 404, validation errors, auth failures

Step 2: Configure backoff parameters

```
max_retries
```
: 3-5 for APIs, 5-10 for infrastructure
```
initial_delay
```
: 0.5-2s
```
max_delay
```
: 30-60s
```
jitter_range
```
: 0.5 (adds +/-50% randomness)

Step 3: Implement with jitter (MANDATORY)

python

undefined

目标：通过递增延迟和抖动重试失败操作。

步骤1：区分可重试与不可重试错误

可重试：408、429、500、502、503、504、网络超时、连接拒绝
不可重试：400、401、403、404、验证错误、认证失败

步骤2：配置退避参数

```
max_retries
```
：API场景3-5次，基础设施场景5-10次
```
initial_delay
```
：0.5-2s
```
max_delay
```
：30-60s
```
jitter_range
```
：0.5（添加±50%的随机性）

步骤3：结合抖动实现（强制要求）

python

undefined

Core pattern (full implementation in references/implementation-patterns.md)

核心模式（完整实现见references/implementation-patterns.md）

for attempt in range(max_retries + 1): try: return operation() except retryable_exceptions as e: if attempt >= max_retries: raise jitter = 1.0 + random.uniform(-0.5, 0.5) actual_delay = min(delay * jitter, max_delay) time.sleep(actual_delay) delay = min(delay * backoff_factor, max_delay)


**Step 4**: Verify retry behavior with forced failures

**Gate**: Backoff includes jitter, respects max_retries, only retries transient errors. Proceed only when gate passes.


**步骤4**：通过强制失败验证重试行为

**检查点**：退避包含抖动、遵守最大重试次数、仅重试临时错误。仅当检查点通过后才可继续。

Phase 4: RATE LIMIT RECOVERY

阶段4：Rate Limit Recovery（限流恢复）

Goal: Handle HTTP 429 responses using Retry-After headers.

Step 1: Detect 429 status code in response

Step 2: Parse

Retry-After

header (seconds or HTTP-date format)

Step 3: Wait the specified duration, then retry

Step 4: Fall back to default wait (60s) if header missing

See

references/implementation-patterns.md

for full

RateLimitedClient

class.

Gate: Honors Retry-After header when present, uses sensible default when absent. Proceed only when gate passes.

目标：使用Retry-After头处理HTTP 429响应。

步骤1：检测响应中的429状态码

步骤2：解析

Retry-After

头（秒数或HTTP日期格式）

步骤3：等待指定时长后重试

步骤4：如果头缺失，使用默认等待时间（60s）

完整的

RateLimitedClient

类见

references/implementation-patterns.md

。

检查点：存在Retry-After头时遵守该头，缺失时使用合理默认值。仅当检查点通过后才可继续。

Phase 5: HEALTH CHECK WAITING

阶段5：Health Check Waiting（健康检查等待）

Goal: Wait for services to become healthy before proceeding.

Step 1: Define health checks by type

Type	Check	Example
TCP	Port accepting connections	`localhost:5432`
HTTP	Endpoint returns 2xx	`http://localhost:8080/health`
Command	Exit code 0	`pgrep -f 'celery worker'`

Step 2: Set appropriate timeouts (services often need 30-120s to start)

Step 3: Poll all checks, succeed only when ALL pass

Step 4: Report status of each check during waiting

See

references/implementation-patterns.md

for full

wait_for_healthy()

implementation.

Gate: All health checks pass within timeout. Status reported per-check. Proceed only when gate passes.

目标：等待服务进入健康状态后再继续。

步骤1：按类型定义健康检查

类型	检查方式	示例
TCP	端口接受连接	`localhost:5432`
HTTP	端点返回2xx	`http://localhost:8080/health`
命令行	退出码为0	`pgrep -f 'celery worker'`

步骤2：设置合适的超时时间（服务通常需要30-120s启动）

步骤3：轮询所有检查，仅当全部通过时才成功

步骤4：等待过程中报告每个检查的状态

完整的

wait_for_healthy()

实现见

references/implementation-patterns.md

。

检查点：所有健康检查在超时时间内通过，且按检查项报告状态。仅当检查点通过后才可继续。

Phase 6: CIRCUIT BREAKER

阶段6：Circuit Breaker（断路器）

Goal: Prevent cascade failures by failing fast after repeated errors.

Step 1: Configure thresholds

```
failure_threshold
```
: Number of failures before opening (typically 5)
```
recovery_timeout
```
: Time before testing recovery (typically 30s)
```
half_open_max_calls
```
: Successful calls needed to close (typically 3)

Step 2: Implement state machine

CLOSED: Normal operation, count failures
OPEN: Reject immediately, wait for recovery timeout
HALF_OPEN: Allow test calls, close on success streak

Step 3: Add fallback behavior for OPEN state

Step 4: Test all state transitions

CLOSED --(failure_threshold reached)--> OPEN
OPEN   --(recovery_timeout elapsed)---> HALF_OPEN
HALF_OPEN --(success streak)----------> CLOSED
HALF_OPEN --(any failure)-------------> OPEN

See

references/implementation-patterns.md

for full

CircuitBreaker

class.

Gate: All four state transitions work correctly. Fallback provides degraded service. Proceed only when gate passes.

目标：在多次错误后快速失败，防止级联故障。

步骤1：配置阈值

```
failure_threshold
```
：触发打开状态的失败次数（通常为5次）
```
recovery_timeout
```
：测试恢复前的等待时间（通常为30s）
```
half_open_max_calls
```
：关闭状态所需的成功调用次数（通常为3次）

步骤2：实现状态机

CLOSED：正常运行，统计失败次数
OPEN：立即拒绝调用，等待恢复超时
HALF_OPEN：允许测试调用，连续成功则关闭

步骤3：为OPEN状态添加回退行为

步骤4：测试所有状态转换

CLOSED --(达到失败阈值)--> OPEN
OPEN   --(恢复超时到期)---> HALF_OPEN
HALF_OPEN --(连续成功)----------> CLOSED
HALF_OPEN --(任意失败)-------------> OPEN

完整的

CircuitBreaker

类见

references/implementation-patterns.md

。

检查点：四个状态转换均正常工作，回退行为提供降级服务。仅当检查点通过后才可继续。

Examples

示例

Example 1: Flaky Test with sleep()

示例1：含sleep()的不稳定测试

User says: "This test uses sleep(5) and sometimes fails in CI" Actions:

Identify as Simple Polling pattern (Phase 1)
Define condition: what the test is actually waiting for (Phase 2, Step 1)

Replace

sleep(5)

with

wait_for(condition, description, timeout=30)

(Phase 2, Step 3)

Run test 3 times to verify reliability (Phase 2, Step 4)
Verify timeout path: force condition to never be true, confirm TimeoutError Result: Deterministic test that adapts to execution speed

用户需求：“这个测试使用sleep(5)，在CI中有时会失败” 操作步骤：

识别为Simple Polling模式（阶段1）
定义条件：测试实际等待的对象（阶段2，步骤1）

用

wait_for(condition, description, timeout=30)

替换

sleep(5)

（阶段2，步骤3）

运行测试3次以验证可靠性（阶段2，步骤4）
验证超时路径：强制条件永远为假，确认抛出TimeoutError 结果：可适配执行速度的确定性测试

Example 2: API Integration with Rate Limits

示例2：带限流的API集成

User says: "Our batch job hits 429 errors from the API" Actions:

Identify as Rate Limit Recovery + Exponential Backoff (Phase 1)
Classify errors: 429 is retryable, 400/401/404 are not (Phase 3, Step 1)
Add Retry-After header parsing with 60s default fallback (Phase 4)
Add exponential backoff with jitter for non-429 transient errors (Phase 3, Step 3)
Test: normal flow, 429 handling, exhausted retries, non-retryable errors Result: Resilient API client that respects rate limits

用户需求：“我们的批处理作业触发了API的429错误” 操作步骤：

识别为Rate Limit Recovery + Exponential Backoff模式（阶段1）
错误分类：429为可重试错误，400/401/404为不可重试错误（阶段3，步骤1）
添加Retry-After头解析，默认回退60s（阶段4）
为非429临时错误添加带抖动的exponential backoff（阶段3，步骤3）
测试：正常流程、429处理、重试耗尽、不可重试错误结果：尊重限流规则的健壮API客户端

Example 3: Service Startup in Docker Compose

示例3：Docker Compose中的服务启动

User says: "App crashes because it starts before the database is ready" Actions:

Identify as Health Check Waiting (Phase 1)
Define checks: TCP on postgres:5432, HTTP on api:8080/health (Phase 5, Step 1)
Set 120s timeout with 2s poll interval (Phase 5, Step 2)
Implement wait_for_healthy() with all-pass requirement (Phase 5, Step 3)
Verify: services start within timeout, timeout fires when service is down Result: Reliable startup ordering without arbitrary sleep()

用户需求：“应用崩溃，因为它在数据库就绪前就启动了” 操作步骤：

识别为Health Check Waiting模式（阶段1）
定义检查项：postgres:5432的TCP检查、api:8080/health的HTTP检查（阶段5，步骤1）
设置120s超时，2s轮询间隔（阶段5，步骤2）
实现
```
wait_for_healthy()
```
，要求所有检查通过（阶段5，步骤3）
验证：服务在超时时间内启动，服务宕机时触发超时结果：无需任意sleep()的可靠启动顺序

Error Handling

错误处理

Error: "Timeout expired before condition met"

错误：“Timeout expired before condition met”

Cause: Condition never became true within timeout window Solution:

Verify condition function logic is correct
Increase timeout if operation legitimately needs more time
Add logging inside condition to observe state changes
Check for deadlocks or blocked resources

原因：条件在超时窗口内从未变为真解决方案：

验证条件函数逻辑是否正确
如果操作确实需要更多时间，增加超时时间
在条件函数内添加日志以观测状态变化
检查是否存在死锁或阻塞资源

Error: "All retries exhausted"

错误：“All retries exhausted”

Cause: Operation failed on every attempt including retries Solution:

Distinguish transient from permanent errors in retryable_exceptions
Verify external service is actually reachable
Check if authentication/configuration is correct
Increase max_retries only if error is genuinely transient

原因：包括重试在内的所有尝试均失败解决方案：

在retryable_exceptions中区分临时错误与永久错误
验证外部服务是否可达
检查认证/配置是否正确
仅当错误确实为临时错误时，增加max_retries

Error: "Circuit breaker open"

错误：“Circuit breaker open”

Cause: Failure threshold exceeded, circuit rejecting calls Solution:

Investigate why underlying service is failing
Implement fallback behavior for CircuitOpenError
Wait for recovery_timeout to elapse before testing
Consider adjusting failure_threshold for known-flaky services

原因：超过失败阈值，断路器拒绝调用解决方案：

调查底层服务失败的原因
为CircuitOpenError实现回退行为
等待recovery_timeout到期后再测试
对于已知不稳定的服务，考虑调整failure_threshold

Anti-Patterns

反模式

Anti-Pattern 1: Arbitrary Sleep Values

反模式1：任意sleep值

What it looks like:

time.sleep(5)

then check result Why wrong: Works on fast machines, fails under load. Wastes time when fast, races when slow. Do instead:

wait_for(condition, description, timeout=30)

表现：

time.sleep(5)

后检查结果问题：在快速机器上正常工作，在负载下失败。快的时候浪费时间，慢的时候会竞争资源。 正确做法：使用

wait_for(condition, description, timeout=30)

Anti-Pattern 2: No Maximum Timeout

反模式2：无最大超时

What it looks like:

while not condition(): time.sleep(0.1)

with no deadline Why wrong: Hangs indefinitely if condition never met. Blocks CI pipelines forever. Do instead: Always set a deadline with

time.monotonic() + timeout

表现：

while not condition(): time.sleep(0.1)

无截止时间问题：如果条件永远不满足，会无限挂起，永久阻塞CI流水线。 正确做法：始终用

time.monotonic() + timeout

设置截止时间

Anti-Pattern 3: Backoff Without Jitter

反模式3：无抖动的退避

What it looks like:

delay *= 2

with exact exponential growth Why wrong: Thundering herd -- all clients retry simultaneously, amplifying load spikes Do instead:

delay * random.uniform(0.5, 1.5)

to spread retries

表现：

delay *= 2

精确指数增长问题：惊群效应——所有客户端同时重试，放大负载峰值 正确做法：使用

delay * random.uniform(0.5, 1.5)

分散重试

Anti-Pattern 4: Retrying Non-Retryable Errors

反模式4：重试不可重试错误

What it looks like:

except Exception: retry()

catching everything Why wrong: 400/401/404 will never succeed on retry. Wastes time and quota. Do instead: Only retry transient errors (408, 429, 500, 502, 503, 504)

表现：

except Exception: retry()

捕获所有错误问题：400/401/404错误重试永远不会成功，浪费时间和配额。 正确做法：仅重试临时错误（408、429、500、502、503、504等）

Anti-Pattern 5: Busy Waiting

反模式5：忙等

What it looks like:

while not ready: pass

or polling every 1ms Why wrong: Burns CPU, causes thermal throttling, starves other processes Do instead: Minimum 10ms for local ops, 100ms+ for external services, 1-5s for network

表现：

while not ready: pass

或每1ms轮询一次问题：占用CPU，导致热节流，饿死其他进程 正确做法：本地操作至少10ms间隔，外部服务至少100ms间隔，网络服务1-5s间隔

References

参考

This skill uses these shared patterns:

Anti-Rationalization - Prevents shortcut rationalizations
Verification Checklist - Pre-completion checks

本技能使用以下共享模式：

Anti-Rationalization - 防止捷径合理化
Verification Checklist - 完成前检查

Domain-Specific Anti-Rationalization

领域特定的反合理化

Rationalization	Why It's Wrong	Required Action
"sleep(5) is long enough"	Timing assumptions break under load	Replace with condition-based polling
"Jitter isn't necessary for small scale"	Scale changes; thundering herd hits early	Always add jitter to backoff
"No need for timeout, it always succeeds"	Always ≠ will always	Add timeout with descriptive error
"Retry everything, it's safer"	Retrying permanent errors wastes resources	Classify retryable vs non-retryable

合理化理由	问题所在	要求操作
"sleep(5)足够长了"	时序假设在负载下会失效	替换为基于条件的轮询
"小规模场景不需要抖动"	规模会变化，惊群效应出现得比预期早	始终为退避添加抖动
"不需要超时，它总会成功"	现在成功不代表永远成功	添加带描述性错误的超时
"重试所有错误更安全"	重试永久错误浪费资源	区分可重试与不可重试错误

Recommended Poll Intervals

Target Type	Min Interval	Typical Interval	Example
In-process state	10ms	50-100ms	Flag, queue, state machine
Local file/socket	100ms	500ms	File exists, port open
Local service	500ms	1-2s	Database, cache
Remote API	1s	5-10s	HTTP endpoint, cloud service

目标类型	最小间隔	典型间隔	示例
进程内状态	10ms	50-100ms	标志、队列、状态机
本地文件/套接字	100ms	500ms	文件存在、端口打开
本地服务	500ms	1-2s	数据库、缓存
远程API	1s	5-10s	HTTP端点、云服务

Reference Files

参考文件

${CLAUDE_SKILL_DIR}/references/implementation-patterns.md

: Complete Python/Bash implementations for all patterns

${CLAUDE_SKILL_DIR}/references/implementation-patterns.md

: 所有模式的完整Python/Bash实现

condition-based-waiting

Original

Translation

Condition-Based Waiting Skill

Condition-Based Waiting Skill（基于条件的等待技能）

Operator Context

操作符上下文

Hardcoded Behaviors (Always Apply)

硬编码行为（始终适用）

Default Behaviors (ON unless disabled)

默认行为（默认启用，可禁用）

Optional Behaviors (OFF unless enabled)

可选行为（默认禁用，可启用）

What This Skill CAN Do

本技能可实现的功能

What This Skill CANNOT Do

本技能无法实现的功能

Quick Reference

快速参考

Instructions

操作步骤

Phase 1: IDENTIFY WAIT PATTERN

阶段1：识别等待模式

Phase 2: SIMPLE POLLING

阶段2：Simple Polling（简单轮询）

Core pattern (full implementation in references/implementation-patterns.md)

核心模式（完整实现见references/implementation-patterns.md）

Phase 3: EXPONENTIAL BACKOFF

阶段3：Exponential Backoff（指数退避）

Core pattern (full implementation in references/implementation-patterns.md)

核心模式（完整实现见references/implementation-patterns.md）

Phase 4: RATE LIMIT RECOVERY

阶段4：Rate Limit Recovery（限流恢复）

Phase 5: HEALTH CHECK WAITING

阶段5：Health Check Waiting（健康检查等待）

Phase 6: CIRCUIT BREAKER

阶段6：Circuit Breaker（断路器）

Examples

示例

Example 1: Flaky Test with sleep()

示例1：含sleep()的不稳定测试

Example 2: API Integration with Rate Limits

示例2：带限流的API集成

Example 3: Service Startup in Docker Compose

示例3：Docker Compose中的服务启动

Error Handling

错误处理

Error: "Timeout expired before condition met"

错误：“Timeout expired before condition met”

Error: "All retries exhausted"

错误：“All retries exhausted”

Error: "Circuit breaker open"

错误：“Circuit breaker open”

Anti-Patterns

反模式

Anti-Pattern 1: Arbitrary Sleep Values

反模式1：任意sleep值

Anti-Pattern 2: No Maximum Timeout

反模式2：无最大超时

Anti-Pattern 3: Backoff Without Jitter

反模式3：无抖动的退避

Anti-Pattern 4: Retrying Non-Retryable Errors

反模式4：重试不可重试错误

Anti-Pattern 5: Busy Waiting

反模式5：忙等

References

参考

Domain-Specific Anti-Rationalization

领域特定的反合理化

Recommended Poll Intervals

推荐轮询间隔

Reference Files

参考文件