retry/LOCAL SIMULATION · ZERO REQUESTSSource ↗

A reliability laboratory

Failure is a condition.
Retry is a decision.

Give a policy a sequence of failures. See when it waits, when it tries again, and when it should stop.

Set the policy

01

A caller must establish retry safety. A timeout alone cannot prove an operation failed.

Status 200–599 or "network"; durationMs; optional retryAfter text. The list is finite. A late response is discarded on timeout.

Read the outcome

02

Follow the time

AttemptWaitVirtual time, milliseconds
0 ms
At / msEventDecision

What the policy means

The waiting is intentional.

Local backoff doubles after each retryable failure, up to its cap. Equal jitter draws from the upper half of that window; full jitter uses the whole window. Both have a 1 ms floor.

A server delay is a lower bound

The actual wait is the larger of local backoff and Retry-After. A local cap never shortens that server delay. If a deadline arrives first, the operation stops.

Bounded, inspectable, reproducible

The same policy, fixture and seed produce the same trace. No real sleeping, recursive retry calls, or background title threads are needed.

An honest continuation

This is the maintained successor to the historical tiktodv4 fork. The original automation is preserved as inert source with upstream credit. This lab does not send engagement, bypass challenges, or evaluate a live service.

Read the project history ↗

Retry-After supports integer seconds and preferred IMF-fixdate syntax. This teaching simulator is not a complete HTTP client.