iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
Browser-test retries are safe only when repeating the underlying action is safe. A test runner can rerun a test, but its retry setting cannot prevent a second order, payment, or other side effect. If a timeout or browser crash leaves it unclear whether an action completed, treat the result as unknown: check authoritative application state before sending the action again. Where possible, use a stable operation identifier and server-side deduplication.
Why a retry can repeat a side effect
A browser automation attempt has several layers: a locator action such as clicking Submit, a network request, a whole test, or a multi-step workflow. A retry repeats whichever layer you configure. The broader the retry boundary, the more actions may run again.
Consider a test that submits an order and then waits for a confirmation page. The server may create the order, but the browser may time out before displaying confirmation. Clicking Submit again because the test failed can create a second order. A timeout says that the automation did not observe success in time; by itself, it does not establish that the server did nothing.
- Read-only checks: revisiting a page, reading an order status, or querying an operation-status endpoint usually observes state rather than creating a new business action.
- Side effects: submitting an order, charging a payment method, creating a user, or sending a message may change state. Repeating the action can duplicate that effect unless the application prevents it.
HTTP idempotency is a useful way to think about repetition, but an HTTP method’s semantics do not automatically make a multi-step browser workflow safe to replay. The HTTP specification describes method semantics, not a blanket guarantee for a sequence of UI actions: RFC 9110: HTTP Semantics.
#1 Best Overall
What to do when submission times out
- Stop before replaying. Do not assume that a missing confirmation means the action failed.
- Reconcile with authoritative state. Look up the resulting record or query the application’s operation-status endpoint using information tied to the attempted action. Prefer a server-side source of truth over a transient button state or a stale page.
- Decide from the result. If the operation succeeded, continue from that state rather than submitting again. If it definitively failed and the application permits a retry, retry using the same logical-operation identifier when available. If the result remains unknown, do not blindly replay a consequential action; use an application-specific recovery path or surface the uncertainty.
- Record what happened. Preserve the attempt’s logs, trace, request details, and operation identifier so a later diagnosis can distinguish a failure to observe confirmation from a failure to perform the action.
The key distinction is between “the operation did not happen” and “the automation did not see evidence that it happened.” Only the former makes an unguarded replay straightforward.
Make side effects safe at the application boundary
Use a stable operation identifier
When the application supports idempotency keys or an equivalent operation identifier, generate one for the logical action and keep it unchanged across attempts to complete that same action. The server can then recognize a replay and return or expose the existing result instead of creating another effect. A new logical action should receive a new identifier; reusing one across unrelated actions can suppress legitimate work.
Deduplicate on the server
Client-side logic alone cannot reliably resolve whether a request reached the server before a connection failed. Server-side deduplication can make repeated submissions converge on one logical operation. Its exact behavior—such as how long a key remains valid and what response a duplicate receives—is application-specific, so tests should follow the service’s documented contract rather than assume one.
Quick wins for a faster PC:
Clear out junk files and repair common Windows errorsFree Scan →Fix the driver behind crashes, sound loss and screen glitchesFind Drivers →Reconcile when no key is available
If the application has no idempotency mechanism, query for a result using a stable business identifier or another authoritative lookup before replay. If neither a reliable lookup nor deduplication exists, automation cannot guarantee that an ambiguous side effect will not happen twice. That is an application design limitation, not a setting a test runner can fix.
Choose the retry boundary deliberately
Before enabling retries, identify exactly what will run again and what evidence is available about the first attempt. These alternatives have different risks:
| Retry boundary | What may run again | When it is useful | Main risk or requirement |
|---|---|---|---|
| Locator action | A click, fill, or other browser interaction | Recovering from a transient interaction failure when the action is safe or guarded | A repeated click may submit twice; first check whether the intended state already exists. |
| Request or operation | A request associated with one logical action | Retrying a transient request when the service supports stable keys, deduplication, or authoritative reconciliation | A lost response leaves the outcome ambiguous; the server contract determines whether replay is safe. |
| Complete test | All test steps, potentially including setup and side effects | Rerunning an isolated test after a transient failure | Every repeated step must tolerate reruns, and test data must not conflict with the earlier attempt. |
| Larger workflow | Multiple tests or business steps | Recovering a workflow designed with checkpoints and explicit recovery behavior | The larger scope increases the number of repeated actions and the need for state reconciliation. |
For each boundary, assess the severity of a duplicate effect, whether current state can be queried, whether a stable key or deduplication exists, how many actions are repeated, the cost of resetting fixtures, test isolation, and visibility into the original attempt. The more consequential the effect and the less observable the first attempt, the less appropriate a blind retry becomes.
Configure test retries without mistaking them for safety
Playwright Test retries are disabled by default. When configured, the runner retries failed tests up to the maximum you set. A test that fails and then passes on retry is reported as flaky, and Playwright discards the failed worker and starts a new worker for the retry. These runner behaviors help detect and contain flaky tests; they do not reverse or deduplicate application side effects. See Playwright Test: Retries.
Playwright recommends independent tests because they are easier to retry. Its retry state can also be used to apply retry-specific handling, such as clearing server-side state before another attempt. A reset must be deliberate: it should remove only data owned by that test and must not conceal a production-like duplicate effect that the test is meant to detect.
- Use unique test data or an explicit reset mechanism so a rerun does not collide with records from the first attempt.
- Make setup and cleanup safe to execute more than once; cleanup should handle both fully created data and partial setup.
- Keep tests independent rather than relying on another test’s side effects or execution order.
- When testing deduplication, preserve the same operation identifier for the repeated logical action and assert that the application exposes only the intended result.
A green retry is a signal that the test was flaky, not proof that its first attempt had no effect. Inspect the first attempt before treating the retry as harmless.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Wait for application state, not elapsed time
Many apparent failures are timing races: the test checks too early, or an arbitrary pause is too short or unnecessarily long. Selenium identifies these races as a common cause of flaky tests. Prefer waiting for the condition that matters—such as a visible confirmation, a changed status, or a completed navigation—rather than sleeping for a guessed duration. See Selenium: Waiting Strategies.
In Playwright, web-first assertions re-check a condition until it succeeds or its timeout expires. The documented default assertion timeout is five seconds; it is a framework default, not a guarantee that every application operation completes within that period. Choose an appropriate timeout for the behavior under test and assert the meaningful state. See Playwright: Assertions.
With Selenium, avoid mixing implicit and explicit waits: their interaction can make total timeout behavior unpredictable. Selenium’s WebDriver supports controlling browsers locally or remotely, but execution location does not change the need to synchronize on application state: Selenium: WebDriver.
Keep evidence from failed and retried attempts
When a CI test fails, retain enough evidence to determine whether the original action reached the application and what state followed. Playwright recommends traces for CI failures; its trace viewer can show a timeline, DOM snapshots, and network requests. See Playwright: Best Practices.
Quick Recap
- Capture the trace or equivalent browser and network evidence for the failed attempt, not only the passing retry.
- Log the test identity, attempt number, and stable operation identifier where appropriate.
- Use traces alongside authoritative application records; a browser trace can show what the client observed, but the server’s operation state is the decisive evidence of a consequential effect.
- Investigate retry-passing tests rather than increasing retry counts to make the suite appear green.
A practical decision rule
- Is the action read-only? A repeated state check is generally safer than repeating a write, though it still needs correct synchronization.
- Can a duplicate cause harm or confusing data? If yes, require a stable operation key, server-side deduplication, or a reliable state check before replay.
- Can you establish what the first attempt did? If yes, reconcile and continue from the observed state. If not, treat the outcome as unknown rather than assuming failure.
- What does the configured retry repeat? Confirm whether it reruns a click, a test, setup, cleanup, or an entire workflow, and make each repeated component safe.
- Can you explain a retry pass? Preserve evidence and investigate it as a flaky-test signal, not as proof that the original attempt was side-effect free.
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
