Handling rate limits and errors in LangChain - Performance & Optimization

Performance: Handling rate limits and errors

MEDIUM IMPACT

This concept affects how quickly the application recovers from API rate limits and errors, impacting user interaction speed and reliability.

Managing API calls when hitting rate limits

LangChain

import asyncio

async def fetch_data():
    response = await api_call()
    if response.status_code == 429:
        await asyncio.sleep(2)  # wait before retry
        return await api_call()
    return response

Delays retries to avoid rapid repeated failures, reducing load and improving responsiveness.

📈 Performance GainReduces blocking retries, improving INP and preventing UI freezes.

Managing API calls when hitting rate limits

LangChain

async def fetch_data():
    response = await api_call()
    if response.status_code == 429:
        # Just retry immediately
        return await api_call()
    return response

Immediate retries on rate limit cause repeated failures and block UI responsiveness.

📉 Performance CostBlocks interaction for multiple retries, increasing INP by hundreds of milliseconds.

Performance Comparison

Pattern	DOM Operations	Reflows	Paint Cost	Verdict
Immediate retry on 429 error	Minimal	0	0	[X] Bad
Retry with delay (exponential backoff)	Minimal	0	0	[OK] Good

Rendering Pipeline

When rate limits or errors occur, the app must pause or retry API calls. This affects the interaction phase where user input waits for responses.

→JavaScript Execution

→Network

→Interaction Handling

⚠️ BottleneckInteraction Handling due to blocked or delayed API responses

Core Web Vital Affected

INP

This concept affects how quickly the application recovers from API rate limits and errors, impacting user interaction speed and reliability.

Optimization Tips

1Avoid immediate retries on rate limit errors to prevent UI blocking.

2Use delays or exponential backoff to space out retries and reduce load.

3Handle errors asynchronously to keep the interface responsive.

Performance Quiz - 3 Questions

What is the main performance problem with immediately retrying API calls after a rate limit error?

A It causes repeated failures and blocks UI responsiveness.

B It reduces bundle size.

C It improves Largest Contentful Paint.

D It decreases network latency.

DevTools: Performance

How to check: Record a session while triggering rate limits. Look for long tasks or blocked frames during retries.

What to look for: High INP values and long tasks indicate poor error handling causing UI delays.

Practice

1. What is the main reason to handle rate limits when using Langchain with APIs?

easy

A. To avoid being blocked by the API provider

B. To speed up the API responses

C. To reduce the size of the data returned

D. To change the API endpoint automatically

Solution

1. Step 1: Understand what rate limits are

   Rate limits restrict how many requests you can send to an API in a time frame.

2. Step 2: Identify the consequence of ignoring rate limits

   If you exceed limits, the API may block your requests temporarily or permanently.

3. Final Answer:

   To avoid being blocked by the API provider -> Option A

4. Quick Check:

   Handling rate limits prevents blocking [OK]

Hint: Rate limits protect APIs from overload; handle to avoid blocks [OK]

Common Mistakes:

• Thinking rate limits speed up responses
• Believing rate limits reduce data size
• Assuming rate limits change endpoints

2. Which of the following is the correct way to catch an API rate limit error in Langchain using Python?

easy

A. client.call().onError(handle_limit)

B. if client.call() == 'RateLimitError':\n handle_limit()

C. client.call().catch(RateLimitError, handle_limit)

D. try:\n response = client.call()\nexcept RateLimitError:\n handle_limit()

Solution

1. Step 1: Recognize Python error handling syntax

   Python uses try-except blocks to catch exceptions like RateLimitError.

2. Step 2: Match the correct syntax for catching exceptions

   try:\n response = client.call()\nexcept RateLimitError:\n handle_limit() uses try-except with RateLimitError, which is correct Python syntax.

3. Final Answer:

   try:\n response = client.call()\nexcept RateLimitError:\n handle_limit() -> Option D

4. Quick Check:

   Python exceptions use try-except [OK]

Hint: Use try-except to catch errors in Python [OK]

Common Mistakes:

• Using if to check exceptions instead of try-except
• Using JavaScript style .catch() in Python
• Calling onError which is not Python syntax

3. Given this Langchain code snippet, what will be printed if the API rate limit is hit and the retry logic waits 2 seconds before retrying?

import time
from langchain import Client

client = Client()

try:
    response = client.call()
except RateLimitError:
    print('Rate limit hit, retrying...')
    time.sleep(2)
    response = client.call()
print(response)

medium

A. Raises RateLimitError and stops without printing

B. Prints 'Rate limit hit, retrying...' then the successful response

C. Prints only the successful response without message

D. Prints 'Rate limit hit, retrying...' and then raises error again

Solution

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

   If RateLimitError occurs, it prints the message and waits 2 seconds before retrying.

2. Step 2: Analyze the retry call

   The second call after sleep is expected to succeed, so response is printed after the message.

3. Final Answer:

   Prints 'Rate limit hit, retrying...' then the successful response -> Option B

4. Quick Check:

   Retry after wait prints message then response [OK]

Hint: Retry after catching error prints message then result [OK]

Common Mistakes:

• Assuming no message prints on error
• Thinking error stops program immediately
• Believing retry always fails again

4. Identify the error in this Langchain error handling code snippet:

try:
    response = client.call()
except RateLimitError:
    print('Rate limit hit')
    client.call()
print(response)

medium

A. The RateLimitError exception is misspelled

B. The print statement is outside the try block and will never run

C. The retry call is not inside a try-except block, so errors may crash the program

D. The client.call() method cannot be called twice

Solution

1. Step 1: Check error handling for retry call

   The retry call after catching error is not protected by try-except, so if it fails again, program crashes.

2. Step 2: Confirm other parts are correct

   Print statement is valid outside try; RateLimitError spelling is correct; calling twice is allowed.

3. Final Answer:

   The retry call is not inside a try-except block, so errors may crash the program -> Option C

4. Quick Check:

   Retry without try-except risks crashes [OK]

Hint: Always wrap retries in try-except to avoid crashes [OK]

Common Mistakes:

• Ignoring retry call error possibility
• Thinking print outside try never runs
• Assuming method can't be called twice

5. You want to build a Langchain client that automatically retries API calls up to 3 times with increasing wait times (1s, 2s, 4s) when a rate limit error occurs. Which approach correctly implements this behavior?

hard

A. Use a loop with try-except catching RateLimitError, sleep increasing seconds, and break on success

B. Call client.call() once and if it fails, immediately call it 3 more times without waiting

C. Wrap client.call() in a single try-except and retry only once after a fixed 5 second wait

D. Ignore RateLimitError and rely on API to reset limits automatically

Solution

1. Step 1: Understand retry logic with increasing wait times

   Retries should be in a loop, catching errors, waiting longer each time before retrying.

2. Step 2: Evaluate options for correct retry pattern

   Use a loop with try-except catching RateLimitError, sleep increasing seconds, and break on success uses a loop with try-except, sleeps 1, 2, then 4 seconds, and stops on success, matching requirements.

3. Final Answer:

   Use a loop with try-except catching RateLimitError, sleep increasing seconds, and break on success -> Option A

4. Quick Check:

   Loop with increasing wait and try-except = correct retry [OK]

Hint: Loop retries with increasing sleep and try-except [OK]

Common Mistakes:

• Retrying without wait or fixed wait only
• Retrying fixed times without catching errors
• Ignoring errors and not retrying