Retry With Backoff

Section 1: Configure Retry Parameters

1
**REGION Configure Retry Parameters
2
SET strActionName TO $'''REPLACE_WITH_ACTION_NAME'''
3
SET numMaxRetries TO 3
4
SET numBaseDelaySec TO 2
5
SET numAttemptsTaken TO 0
6
SET boolRetrySuccess TO False
7
SET strRetryError TO $'''(none)'''
8
SET numCurrentDelay TO numBaseDelaySec
9
**ENDREGION

Section 2: Retry Loop with Exponential Backoff

1
**REGION Retry Loop with Exponential Backoff
2
LOOP WHILE numAttemptsTaken < numMaxRetries AND boolRetrySuccess = False
3
    SET numAttemptsTaken TO numAttemptsTaken + 1
4
    BLOCK RetryAction
5
    ON BLOCK ERROR
6
        SET strRetryError TO $'''%LastError%'''
7
        IF numAttemptsTaken < numMaxRetries THEN
8
            WAIT numCurrentDelay
9
            SET numCurrentDelay TO numCurrentDelay * 2
10
        END
11
    END
12
        /# ── Place your flaky action(s) here ── #/
13
        SET boolRetrySuccess TO True
14
    END
15
END
16
**ENDREGION

Section 3: Evaluate Retry Outcome

1
**REGION Evaluate Retry Outcome
2
IF boolRetrySuccess = False THEN
3
    SET strRetryError TO $'''[%strActionName%] All %numMaxRetries% attempts failed. Last error: %strRetryError%'''
4
END
5
**ENDREGION

Usage Notes

• Replace REPLACE_WITH_ACTION_NAME with a descriptive name for the action being retried (e.g., $'''Graph API Token Request''')
• Place the action(s) that may fail transiently inside the BLOCK RetryAction — the comment marks the insertion point
• The SET boolRetrySuccess TO True line inside the block runs only if no error occurs — it acts as the success signal to exit the loop
• Backoff doubles each attempt: 2s → 4s → 8s by default. Adjust numBaseDelaySec for faster or slower retry cadences
• Adjust numMaxRetries based on the action — use 3 for API calls, 5 for file locks, 2 for quick checks
• After the loop, check boolRetrySuccess to determine if the action ultimately succeeded or all retries were exhausted
• strRetryError contains the last error message if all retries fail — use it in downstream error logging
• This pattern works well inside the Error Handler Wrapper for nested resilience (retry first, then escalate)

Requirements

• No external dependencies — uses only built-in PAD loop, block, and wait actions
• The action placed inside the retry block must be idempotent (safe to repeat without side effects)
• WAIT action requires PAD flow control actions (included in all PAD versions)
• For API-based retries, ensure the endpoint supports repeated requests (most REST APIs do)
• Error variable LastError is a built-in PAD object available inside ON BLOCK ERROR handlers