WJb Docs - Intermediate

🔁 Basic Retry

WJb supports automatic retries through JobOptions.

The action itself stays clean — it just throws when something goes wrong. The retry policy is defined outside the action.

---

Enabling Retry

When enqueueing a job you can supply options:

await wjb.EnqueueAsync("send-email",
    new EmailInput { To = "user@test.com" },
    new JobOptions
    {
        // retry configuration
    });

The exact properties available depend on the version, but the common pattern is:

• Maximum number of attempts
• Delay between attempts (fixed or calculated)

---

How Retry Works

1. The action throws an exception. 2. The job is marked as failed (temporarily). 3. If attempts remain, WJb schedules the same job again after the configured delay. 4. The action is executed once more with the original payload. 5. This repeats until success or the retry limit is reached.

Attempt 1 → Fail
    ↓ (delay)
Attempt 2 → Fail
    ↓ (delay)
Attempt 3 → Success → Complete

or

Attempt 1 → Fail
Attempt 2 → Fail
Attempt 3 → Fail → Final Failed state

---

Example with Delay

var options = new JobOptions
{
    // example shape – adjust to actual API
    // MaxRetries = 3,
    // RetryDelay = TimeSpan.FromSeconds(30)
};
await wjb.EnqueueAsync("send-email", payload, options);

You can also implement custom delay logic via GetRetryDelay(attempt) when available.

---

Important Characteristics

• The same payload is used on every retry
• The action code does not need to know about retries
• Side effects inside the action should be idempotent when possible
• After the final failed attempt the job stays in the Failed state

---

When to Use Basic Retry

Use automatic retry for:

• Transient network errors
• Temporary unavailability of external services
• Rate limiting that resolves after a short wait

Do not use basic retry for:

• Permanent validation errors
• Business rule violations
• Logic bugs

Those should fail immediately (or be handled with explicit compensating actions).

---

Key Point

Retry is a policy applied to the job, not logic inside the action.

The action throws. The options decide whether (and when) the job will be tried again.