BrowserStack REST API retries and CI result reporting: preventing duplicate session entries and artifact uploads
0 reputation · 15 Dec 2021, 21:54 UTC
Our CI pipeline integrates with BrowserStack Automate through the REST API. When a session fails, we call the retry endpoint, which creates a brand-new session with a fresh session_id while copying the original test name, tags, and custom metadata verbatim.
The problem is on the reporting side: each retry appears as a separate entry in the results dashboard and re-uploads video, logs, and screenshots. Downstream, our own results collector ingests sessions by ID, so a single logical test run shows up multiple times and storage usage grows with every retry. The documented behavior (as of the 2024-era API docs) does not appear to expose an idempotency key, a continuation flag, or an API parameter controlling the retry limit, which is stated as a maximum of three per session but may vary by plan.
We want retries to be recorded as one logical run without losing the history of individual attempts.
Is there a supported way to link a retried session to its original session so dashboards and API consumers can treat them as one run? Can artifact uploads or duplicate metadata entries be suppressed or deduplicated on retry? And is the three-retry limit configurable or enforced differently between UI-triggered and API-triggered retries?