Protractor 7.0.0: Handling Retries Without Duplicate Writes

Goal

In Protractor 7.0.0, tests that perform state‑changing operations (e.g., database inserts, API calls, file writes) must be retried on failure without duplicating those side effects. The framework relies on Jasmine’s built‑in retry syntax or third‑party retry packages; there is no native retry configuration in Protractor’s own config file.

Constraints & Uncertainty

Retries re‑execute the entire it block, which can re‑trigger side effects unless tests are idempotent or cleanup hooks are used. Zone.js synchronization may mask async errors on the first run but surface them on a retry, leading to non‑deterministic outcomes. There is no documented mechanism for snapshotting or restoring browser/application state between retry attempts, and the Angular team has deprecated Protractor without adding new retry features.

Specific Questions

1. Should retry logic be implemented solely at the Jasmine level (e.g., fit, fdescribe), or is a Protractor‑level plugin that manages state snapshots required to avoid duplicate writes?
2. If a plugin is used, what minimal API or configuration should it expose to allow test authors to specify which stateful operations need restoration?
3. How can we reliably detect and prevent duplicate side effects when a test is retried, given that Protractor’s current architecture does not provide hooks for pre‑retry cleanup?