How do you validate API retries with Playwright intercepts?

Question

QA Hacks Team · Accepted Answer

Validating API retries with Playwright intercepts involves simulating initial failures and subsequent successes, then asserting the number of requests and the final application state. The core mechanism is `page.route()`, which allows precise control over network requests.

**1. Define the Scenario:**
First, identify the API endpoint and the retry strategy (e.g., number of retries, backoff mechanism, specific error codes that trigger retries) implemented by the client.

**2. Implement Network Interception:**
Use `page.route(urlMatcher, handler)` to intercept the target API request. The handler function will be invoked for each request matching the `urlMatcher`.

**3. Simulate Transient Failures:**
Inside the handler, maintain a counter or a state variable to track the number of times the request has been intercepted.
*   For the *initial* request and subsequent *retry attempts* up to a certain threshold (e.g., `maxRetries - 1`), fulfill the request with an error status (e.g., `500 Internal Server Error`, `408 Request Timeout`) or `abort()` it. This simulates the transient failure.
*   For the *final retry attempt* that is expected to succeed, fulfill the request with a `200 OK` status and the expected successful payload.

**4. Track Request Counts:**
Increment the counter within the route handler for every request intercepted. This counter is critical for asserting that the expected number of retries occurred.

**5. Trigger and Assert:**
After setting up the route, perform the user action that triggers the API call. Then, assert:
*   The final count of intercepted requests matches `1 (initial call) + expected retries`.
*   The UI or application state correctly reflects the data from the final, successful API response.

**Example Implementation Snippet:**

```typescript
let requestCount = 0;
const targetApi = '/api/data';
const maxExpectedClientRetries = 2; // Client-side retries 2 times after initial failure

await page.route(new RegExp(targetApi), async route => {
  requestCount++;
  if (requestCount <= maxExpectedClientRetries) { // Fail initial and first retry
    await route.fulfill({
      status: 500,
      contentType: 'application/json',
      body: JSON.stringify({ message: 'Simulated server error' }),
    });
  } else { // Succeed on the subsequent attempt (e.g., the 3rd total attempt)
    await route.fulfill({
      status: 200,
      contentType: 'application/json',
      body: JSON.stringify({ data: 'Successful retry payload' }),
    });
  }
});

// Assuming a UI action or page load triggers the API call
await page.goto('http://localhost:3000'); 
await page.click('#load-data-button');

// Assertions
expect(requestCount).toBe(1 + maxExpectedClientRetries); // 1 initial + 2 retries = 3 requests
await expect(page.locator('#data-display')).toHaveText('Successful retry payload');
```

**Best Practices:**
*   **Clear State Management:** Ensure `requestCount` or similar state is isolated per test or reset between tests using `test.beforeEach`.
*   **Dynamic Response Bodies:** Parameterize error and success responses to match expected application behavior.
*   **Edge Cases:** Test scenarios where `maxRetries` are reached without success, leading to an application error state.
*   **Framework Integration:** Encapsulate retry test logic within a utility function or a Playwright test fixture for reusability and cleaner tests.

This approach provides granular control, enabling robust validation of complex client-side retry logic and enhancing application resilience.

### Speaking Blueprint (3-Minute Verbal Response):
[The Hook]
Ensuring robust client-server communication, especially under transient network conditions, is paramount for modern web applications. Our automation frameworks must rigorously validate these resilience mechanisms, and Playwright's powerful network interception capabilities offer a precise and efficient way to do exactly that.

[The Core Execution]
When we're validating API retries, the core idea is to simulate transient failures for an initial request and then allow subsequent retries to succeed, all while meticulously tracking the request flow. We leverage Playwright's `page.route()` method for this. For a given API endpoint, we'll set up a route handler. Inside this handler, we introduce a counter to track how many times that specific API call has been intercepted. The first time the request hits our handler, and perhaps for a few subsequent attempts—matching the client's configured retry count—we'll instruct Playwright to fulfill it with a `500 Internal Server Error` or a `408 Request Timeout`—effectively simulating a transient backend issue. After a predefined number of these simulated failures, say, on the third total attempt if the client retries twice, we'll then fulfill the request with a `200 OK` status and the expected successful payload. This allows the client-side retry mechanism to kick in and eventually succeed. After we've triggered the user action that initiates thi

How do you validate API retries with Playwright intercepts?

📋 Interview Context

Overview

Interview Question:

Expert Answer:

Speaking Blueprint (3-Minute Verbal Response):

Continue Learning: Up Next

How do you analyze defect leakage across releases?

How do you assess API dependencies before deployment?

How do you assess API dependency risks before releases?