fetch-kit/http-resilience
11 pinned fetch resilience libraries run against 21 failure scenarios: retries, backoff aborts, hedges, circuit breakers, bulkheads, deduplication, cancellation, real timeouts, and body replay. Every cell is an executed assertion against that library's own terminal error contract, and every failure links to a recorded trace.
Pinned, recorded versions
Each library is pinned and the version actually measured is recorded per run, so every cell traces back to the exact release it was asserted against.
Executed assertions
PASS and FAIL come from assertions run against real traffic, attempt and logical accounting, and each library's terminal error contract - not from release notes or documentation claims.
Failure traces
Every failing cell links to the configuration it ran with, the behaviour it promised, the assertion that broke, and a trace of the failing run.
| Status | Meaning |
|---|---|
| PASS | Observed behaviour matched the asserted contract for that scenario. |
| FAIL | Observed behaviour broke the contract. These are findings, not a broken publication. |
| N/A | The combination is genuinely unavailable; the cell states the reason. |
| NOT TESTED | No implementation of that scenario for that library yet. |
| NOT RUN | A registered case was absent from the run. A published matrix never contains this state. |
Most libraries pass the straightforward retry cases and diverge exactly where they make no explicit promise: interrupting a backoff, removing a queued waiter, or reporting attempt and logical accounting at a circuit boundary.
Read the methodologyClone the repository and you can run: npm cinpm run report