Harvesting Duplicated Retry Logic into Shared Artifacts

In any repository that has survived three years of production, you routinely find multiple implementations of network retry logic.

One lives in the billing client, using hardcoded linear sleeps. Another is buried in an analytics ingestion path, using Math.random() for jitter. A third sits in an internal auth package, quietly ignoring HTTP 429 Retry-After headers and hammering downstream rate limiters.

Everyone acknowledges this is waste. But the standard remedy—a top-down platform initiative to write a greenfield shared networking utility—almost always fails. Developers continue writing their own private loops because the new internal library rarely accounts for the specific runtime quirks their services have accumulated over time.

Why Clean-Slate Libraries Fail

When platform teams attempt a monorepo cleanup, they usually begin by writing what they imagine to be the perfect canonical retry utility. It arrives with twenty configuration options, deeply nested generics, and zero historical context.

The bespoke retry loops scattered throughout your codebase exist for concrete reasons. Each variant reflects an unwritten lesson learned during an outage:

• The payment gateway client retries on socket timeouts, but aborts immediately if the payload was partially sent.
• The search indexer respects upstream exponential backoff, but caps the maximum delay at three seconds to avoid exhausting thread pools.
• The legacy webhook dispatcher checks for specific JSON error structures rather than relying on HTTP status codes alone.

A clean-slate library throws this operational knowledge away. If you want effective code deduplication, you do not design a component from theory. You harvest, compare, and grade the implementations already running in your system.

Running a Code Reuse Audit on Live Variants

A meaningful code reuse audit does not merely count how many times a loop construct appears across your codebase. Listing functions is cosmetic unless those functions can be executed, measured, and verified in isolation.

To extract a reliable shared artifact from duplicate code:

1. Extract and normalise. Parse the AST of every retry wrapper across the codebase. Group them by their input contracts, such as functions taking (operation, attempts, delay) versus those accepting an AbortSignal and explicit backoff strategies.
2. Standardise the failure suite. Write a strict test fixture that exercises the edge cases every network client eventually hits:

• Exponential growth bounds (does delay ever overflow or turn negative?).
• Jitter distribution (does it prevent thundering herds on recovery?).
• Context cancellation (does it release resources immediately when an abort signal fires?).
• Error discrimination (does it rethrow fatal 4xx responses without retrying?).

1. Execute the gauntlet. Run every discovered variant against this single test suite.

// A common failure: unjittered backoff without cancellation support
export async function retryWithBackoff<T>(
  fn: () => Promise<T>,
  retries = 3,
  baseDelayMs = 100
): Promise<T> {
  try {
    return await fn();
  } catch (error) {
    if (retries <= 0) throw error;
    // Missing jitter: all failing callers retry at the exact same millisecond
    await new Promise((resolve) => setTimeout(resolve, baseDelayMs));
    return retryWithBackoff(fn, retries - 1, baseDelayMs * 2);
  }
}

Assigning Verification Verdicts

Running the test gauntlet against harvested variants yields empirical data rather than stylistic opinions. A certification harness evaluates each implementation and records one of four precise verdicts:

• FAILED: The variant violates a hard invariant. The example above fails when tested against concurrent worker bursts (lack of jitter causes immediate collisions) and does not accept an AbortSignal to cancel in-flight work.
• INCONCLUSIVE: The harness cannot exercise the input contract. If an extracted function depends on an internal socket handle or an unmocked global runtime binding, the harness reports inconclusive. This denotes a harness limit, not an artifact defect.
• PROVISIONAL: The implementation executes repeatably and passes structural checks, but correctness across edge cases (such as clock skew or stream truncation) has not yet been asserted.
• CERTIFIED: The implementation handles backoff clamping, decorrelated jitter, cancellation, and error discrimination correctly under synthetic failure conditions.

This grading workflow separates working code from liability. Instead of imposing an unproven greenfield library across all services, you promote the variant that has already survived production constraints and verified execution.