Error handling and retries in DynamoDB - Step-by-Step Execution

Concept Flow - Error handling and retries

Start Operation

↓

Try Operation

↓

Success?

Yes→Return Result

No↓

Check Error Type

↓

Retryable

↓

Retry with Delay

↓

Max Retries Reached?

No→Try Operation

Yes↓

Return Error

This flow shows trying an operation, checking if it succeeded, retrying if the error is retryable, and stopping after max retries or on non-retryable errors.

Execution Sample

DynamoDB

max_retries = 3
attempt = 0
while attempt < max_retries:
    try:
        result = dynamodb.get_item(...)
        break
    except ProvisionedThroughputExceededException:
        attempt += 1
        sleep(2 ** attempt)

This code tries to get an item from DynamoDB, retries on throughput errors with exponential backoff, and stops after 3 tries.

Execution Table

Attempt	Action	Error Occurred	Error Type	Retry?	Wait Time (seconds)	Result/Outcome
1	Try get_item	Yes	ProvisionedThroughputExceededException	Yes	2	Retrying
2	Try get_item	Yes	ProvisionedThroughputExceededException	Yes	4	Retrying
3	Try get_item	No	-	No	0	Success, return result
4	Exit loop	-	-	-	-	Operation completed successfully

💡 Operation succeeded on attempt 3, so loop exits.

Variable Tracker

Variable	Start	After Attempt 1	After Attempt 2	After Attempt 3	Final
attempt	0	1	2	2	2
result	None	None	None	Item data	Item data

Key Moments - 3 Insights

Why do we increase the attempt counter only on retryable errors?

Because as shown in execution_table rows 1 and 2, we only increment 'attempt' when a retryable error occurs to limit retries. Non-retryable errors would stop retries immediately.

What happens if the error is not retryable?

The flow goes to the 'Non-Retryable' branch in concept_flow and stops retries, returning the error immediately without incrementing 'attempt'.

Why do we use exponential backoff for wait time?

Exponential backoff (2, 4 seconds here) reduces load on the service and increases chances of success on retries, as seen in the 'Wait Time' column in execution_table.

Visual Quiz - 3 Questions

Look at the execution_table, what is the value of 'attempt' after the second retry?

A 1

B 2

C 3

D 0

💡 Hint

Check the 'attempt' variable in variable_tracker after Attempt 2.

At which attempt does the operation succeed without error?

A Attempt 1

B Attempt 2

C Attempt 3

D Attempt 4

💡 Hint

See execution_table row where 'Error Occurred' is 'No'.

If the error was non-retryable on the first attempt, what would happen?

A The code retries up to max_retries anyway

B The code stops and returns the error immediately

C The code waits and retries once

D The code ignores the error and returns success

💡 Hint

Refer to concept_flow branch for 'Non-Retryable' errors.

Concept Snapshot

Error handling in DynamoDB involves trying an operation,
checking if it succeeded, and retrying on retryable errors like
ProvisionedThroughputExceededException.
Retries use exponential backoff delays.
Stop retrying after max retries or on non-retryable errors.
Return result on success or error on failure.

Full Transcript

This visual execution trace shows how error handling and retries work in DynamoDB operations. The process starts by attempting the operation. If it succeeds, the result is returned immediately. If an error occurs, the code checks if the error is retryable, such as a throughput exceeded exception. If retryable, it waits using exponential backoff (doubling wait time each retry) and tries again, increasing the attempt count. If the error is non-retryable, it stops retrying and returns the error. The example code tries up to 3 times, and the execution table shows attempts 1 and 2 fail with retryable errors, waiting 2 and 4 seconds respectively, and attempt 3 succeeds. Variables like 'attempt' and 'result' update accordingly. Key moments clarify why attempts increment only on retryable errors, what happens on non-retryable errors, and why exponential backoff is used. The quiz tests understanding of attempt counts, success timing, and error handling branches.

Practice

1. What is the main purpose of using retries in DynamoDB error handling?

easy

A. To ignore all errors and continue processing

B. To permanently stop the operation when an error occurs

C. To automatically try the operation again after a temporary failure

D. To delete the data causing the error

Solution

1. Step 1: Understand retries in DynamoDB

   Retries are used to handle temporary errors like throttling by trying the operation again.

2. Step 2: Identify the purpose of retries

   Retries help keep the app stable by not failing immediately on temporary issues.

3. Final Answer:

   To automatically try the operation again after a temporary failure -> Option C

4. Quick Check:

   Retries = automatic retry after temporary failure [OK]

Hint: Retries mean trying again after temporary errors [OK]

Common Mistakes:

• Thinking retries stop all errors permanently
• Ignoring the need to check error types before retrying
• Assuming retries delete data

2. Which of the following is the correct way to catch a throttling exception in DynamoDB using Python?

easy

A. try:
# operation
except ThrottlingException:
# retry logic

B. try:
# operation
except Exception:
pass

C. if error == 'ThrottlingException':
retry()

D. catch ThrottlingException {
retry();
}

Solution

1. Step 1: Identify Python error handling syntax

   Python uses try-except blocks to catch exceptions, with except specifying the exception type.

2. Step 2: Match correct exception handling for throttling

   try: # operation except ThrottlingException: # retry logic correctly uses try-except with ThrottlingException to handle retries.

3. Final Answer:

   try: # operation except ThrottlingException: # retry logic -> Option A

4. Quick Check:

   Python try-except with specific exception = try: # operation except ThrottlingException: # retry logic [OK]

Hint: Python uses try-except to catch specific exceptions [OK]

Common Mistakes:

• Using incorrect syntax like catch instead of except
• Catching all exceptions without handling specific ones
• Using if statement instead of try-except for exceptions

3. Given this Python code snippet for DynamoDB, what will be the output if a throttling error occurs on the first attempt?

import boto3
from botocore.exceptions import ClientError

client = boto3.client('dynamodb')

try:
    response = client.put_item(TableName='MyTable', Item={'id': {'S': '123'}})
    print('Success')
except ClientError as e:
    if e.response['Error']['Code'] == 'ThrottlingException':
        print('Retrying...')
    else:
        print('Failed')

medium

A. Success

B. Retrying...

C. Failed

D. No output

Solution

1. Step 1: Understand the try-except block behavior

   If a ClientError occurs, the code checks the error code inside the except block.

2. Step 2: Check error code for throttling

   If the error code is 'ThrottlingException', it prints 'Retrying...'. Otherwise, it prints 'Failed'.

3. Final Answer:

   Retrying... -> Option B

4. Quick Check:

   Error code 'ThrottlingException' triggers 'Retrying...' [OK]

Hint: Check error code in except to decide output [OK]

Common Mistakes:

• Assuming success despite error
• Ignoring error code check and printing 'Failed'
• Expecting no output on error

4. Identify the error in this retry logic snippet for DynamoDB in Python:

try:
    response = client.get_item(TableName='MyTable', Key={'id': {'S': '123'}})
except ClientError as e:
    if e.response['Error']['Code'] == 'ThrottlingException':
        client.get_item(TableName='MyTable', Key={'id': {'S': '123'}})
    else:
        raise e

medium

A. No error, code retries correctly

B. Should not raise exception in else block

C. Error code check is incorrect

D. Retry call is not inside a try-except block

Solution

1. Step 1: Analyze retry call placement

   The retry call is made without a try-except block, so if it fails again, it will raise an unhandled exception.

2. Step 2: Understand proper retry handling

   Retries should be wrapped in try-except to handle repeated failures gracefully.

3. Final Answer:

   Retry call is not inside a try-except block -> Option D

4. Quick Check:

   Retry without try-except risks unhandled errors [OK]

Hint: Always wrap retries in try-except to catch repeated errors [OK]

Common Mistakes:

• Not wrapping retry calls in error handling
• Mischecking error codes
• Avoiding raising exceptions on unknown errors

5. You want to implement a retry mechanism for DynamoDB writes that retries up to 3 times with exponential backoff when a throttling error occurs. Which approach correctly combines error handling and retries?

hard

A. Use a loop with try-except catching throttling errors, sleep doubling wait time each retry, stop after 3 attempts

B. Call put_item once, then retry infinitely without delay on any error

C. Ignore errors and assume writes always succeed

D. Use try-except but do not check error codes before retrying

Solution

1. Step 1: Understand retry with exponential backoff

   Retries should be limited in number and wait time should increase to reduce load.

2. Step 2: Combine error handling and retry logic

   Use a loop with try-except to catch throttling errors, sleep with increasing delay, and stop after max retries.

3. Final Answer:

   Use a loop with try-except catching throttling errors, sleep doubling wait time each retry, stop after 3 attempts -> Option A

4. Quick Check:

   Retry loop + exponential backoff + error check = Use a loop with try-except catching throttling errors, sleep doubling wait time each retry, stop after 3 attempts [OK]

Hint: Retry with limited attempts and increasing delay on throttling [OK]

Common Mistakes:

• Retrying infinitely without delay
• Not checking error codes before retrying
• Ignoring errors completely