How much does zuzu.codes cost?

The starter track is free — read all lessons and practice for free. Full access to every track (current and future) is $14.99/month. Cancel anytime.

How long does each track take?

Each track is designed as a 30-day challenge — one lesson per day, about 15 minutes each. Go at your own pace, but the structure is built around daily consistency.

What's the lesson format?

Each lesson is a student-teacher dialogue with code examples, followed by a hands-on code challenge in an in-browser editor. You read, you understand, then you write real code.

Do I need prior coding experience?

Our beginner track starts from absolute zero — no prior experience needed. Advanced tracks build on earlier ones, and the platform tells you exactly where to start.

How is zuzu.codes different from freeCodeCamp or Codecademy?

zuzu.codes uses a structured 30-day track format with dialogue-based teaching, an in-browser code editor, and gamification (XP, streaks, progress tracking). The format builds genuine understanding through daily practice.

Retry an API Call With Attempt Tracking — Automation For Makers

Day 19 · ~12 min●

Transient failures — rate limits, network blips, 5xx responses — are the most common way automations break. A retry wrapper turns a one-shot failure into a brief pause before trying again. What's the loop shape?

for attempt in range(max_attempts) with a try/except inside?

Exactly. The try block makes the call and returns on success. The except block catches the exception. On every attempt except the last, the loop continues. On the last attempt, you re-raise so the caller can see the real error:

python

for attempt in range(1, max_attempts + 1):
    try:
        return toolset.execute_action(action, params)
    except Exception:
        if attempt == max_attempts:
            raise

So the caller gets the happy result on success, or the final exception if every attempt fails?

Right. Transient failures are silent — you retry and move on. Terminal failures propagate so nothing upstream pretends everything worked. Here's the function with attempt tracking:

python

def retry_with_backoff(action: str, params: dict, max_attempts: int) -> dict:
    for attempt in range(1, max_attempts + 1):
        try:
            result = toolset.execute_action(getattr(Action, action), params)
            print(f"Succeeded on attempt {attempt}/{max_attempts}")
            return result
        except Exception as exc:
            print(f"Attempt {attempt}/{max_attempts} failed: {exc}")
            if attempt == max_attempts:
                raise
    return {}

getattr(Action, action) — that lets me pass the action name as a string and still use the enum?

Yes. The wrapper is generic across every action. Pass "GMAIL_FETCH_EMAILS" and the function resolves it to Action.GMAIL_FETCH_EMAILS at runtime. One wrapper, every API.

Combined with yesterday's idempotent creates, this means I can retry writes safely — each retry either finds the existing record or creates it exactly once?

Retry plus idempotency is the core pair of production automation. You can now retry writes without fear of duplicates. Week 4 builds on exactly that combination.

Retry Loop

TL;DR: for attempt in range(1, max_attempts + 1) with try/except — return on success, re-raise on the last failure.

Return inside try — success exits immediately
Re-raise on last attempt — failure propagates only after exhaustion
Attempt count in print — makes transient flakiness visible in logs

Why retry + idempotency = safe

Pair	Effect
retry + non-idempotent	duplicates on every transient failure
retry + idempotent	at most one record, ever

Day 19 · ~12 min●

for attempt in range(max_attempts) with a try/except inside?

python

for attempt in range(1, max_attempts + 1):
    try:
        return toolset.execute_action(action, params)
    except Exception:
        if attempt == max_attempts:
            raise

So the caller gets the happy result on success, or the final exception if every attempt fails?

Right. Transient failures are silent — you retry and move on. Terminal failures propagate so nothing upstream pretends everything worked. Here's the function with attempt tracking:

python

def retry_with_backoff(action: str, params: dict, max_attempts: int) -> dict:
    for attempt in range(1, max_attempts + 1):
        try:
            result = toolset.execute_action(getattr(Action, action), params)
            print(f"Succeeded on attempt {attempt}/{max_attempts}")
            return result
        except Exception as exc:
            print(f"Attempt {attempt}/{max_attempts} failed: {exc}")
            if attempt == max_attempts:
                raise
    return {}

getattr(Action, action) — that lets me pass the action name as a string and still use the enum?

Yes. The wrapper is generic across every action. Pass "GMAIL_FETCH_EMAILS" and the function resolves it to Action.GMAIL_FETCH_EMAILS at runtime. One wrapper, every API.

Combined with yesterday's idempotent creates, this means I can retry writes safely — each retry either finds the existing record or creates it exactly once?

Retry plus idempotency is the core pair of production automation. You can now retry writes without fear of duplicates. Week 4 builds on exactly that combination.

Retry Loop

TL;DR: for attempt in range(1, max_attempts + 1) with try/except — return on success, re-raise on the last failure.

Return inside try — success exits immediately
Re-raise on last attempt — failure propagates only after exhaustion
Attempt count in print — makes transient flakiness visible in logs

Why retry + idempotency = safe

Pair	Effect
retry + non-idempotent	duplicates on every transient failure
retry + idempotent	at most one record, ever

def retry_with_backoff(action: str, params: dict, max_attempts: int) -> dict: for attempt in range(1, max_attempts + 1): try: result = toolset.execute_action(getattr(Action, action), params) print(f"Succeeded on attempt {attempt}/{max_attempts}") return result except Exception as exc: print(f"Attempt {attempt}/{max_attempts} failed: {exc}") if attempt == max_attempts: raise return {}

Retry Loop

TL;DR: for attempt in range(1, max_attempts + 1) with try/except — return on success, re-raise on the last failure.

Return inside try — success exits immediately

Re-raise on last attempt — failure propagates only after exhaustion

Attempt count in print — makes transient flakiness visible in logs

Why retry + idempotency = safe

Pair	Effect
retry + non-idempotent	duplicates on every transient failure
retry + idempotent	at most one record, ever

Retry Loop

TL;DR: for attempt in range(1, max_attempts + 1) with try/except — return on success, re-raise on the last failure.

Return inside try — success exits immediately

Re-raise on last attempt — failure propagates only after exhaustion

Attempt count in print — makes transient flakiness visible in logs

Why retry + idempotency = safe

Pair	Effect
retry + non-idempotent	duplicates on every transient failure
retry + idempotent	at most one record, ever

Retry Loop

Why retry + idempotency = safe

Retry Loop

Why retry + idempotency = safe

Retry Loop

Why retry + idempotency = safe

Sign up to practice

Retry Loop

Why retry + idempotency = safe

Sign up to practice