Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

[Feature]: Allow `retryStrategy: 'isolated'` in test.describe.configure() for tests requiring zero background workers

Chiusa
  • Qualcosa non va?
#43,351 7 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

@alok-108 ci sta già lavorando.

Dal 14/10/2026.

  • #43445 di @yury-s — integrata

Valutazione

Difficoltà
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
22/100
Tipo di issue
Funzionalità
Chiarezza
Abbastanza chiara
Stato di attività
Attiva
Stack tecnologico
typescript
Ambito
testing

Direzione di ricerca

The payload names only the retryStrategy option, the global playwright.config.ts setting, and test.describe.configure(), so start by finding where the global 'isolated' retry strategy is applied in the runner's scheduling. The open question is how a per-describe override can defer retries to a single-worker phase while other workers run. Done means a describe-level retryStrategy: 'isolated' queues only that suite's failed retries for isolation, with a test covering the mixed case. Maintainer design input is needed first.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

🚀 Feature Request

Playwright recently introduced retryStrategy: 'isolated', however, it is currently restricted to the global testConfig. It'd be very helpful if retryStrategy was implemented at the test file level in test.describe.configure() so isolated retries can be targeted only to tests that require zero concurrency to pass.

Existing features do not solve this
  1. Why lock doesn't work:
    lock is an opt-in named mutex, not a runner-wide exclusive lock:
    If Test A has { lock: 'foo' }, it only blocks other tests that also declare { lock: 'foo' }.
    All other unlocked tests in the repository still run concurrently in background workers alongside Test A.
    To achieve true isolation with lock, we would have to add { lock: 'foo' } to every single test in the entire codebase, which would completely eliminate parallel execution for the whole test run.
  2. Why global retryStrategy: 'isolated' in playwright.config.ts is insufficient:
    It is currently an all-or-nothing global flag.
    It forces every failed test across thousands of unrelated files to defer its retries to the single-worker tail phase, even if 99% of tests are completely stateless and should just retry immediately.
Example
import { test, expect } from '@playwright/test';

// Only this suite will be retried in isolation if concurrency causes a failure
test.describe.configure({
  retries: 1,
  retryStrategy: 'isolated',
 });

test.describe('tests that fail under concurrent execution', () => {
  test('exclusive test', async ({ page }) => {
    /* Runs in parallel initially.
    If it collides with another worker and fails, it is retried
    at the end of the run with no other tests running concurrently. */
  });
});

Expected Behaviour:

Global/default retry strategy remains 'immediate' (or whatever is set in playwright.config.ts).
Test files configured with override, retryStrategy: 'isolated' at the test.describe level are queued to run in isolation (one worker, no other concurrent tests running) upon failure.

Motivation

We have specific tests that require zero-concurrency isolation (meaning no other worker threads can be running anywhere in the runner at the same time) to pass as the nature of these tests make them extremely vulnerable to cross-test interference. We want our test suite to run in parallel by default but if these specific tests fail under concurrency, we want their retries to run in isolation without background workers.

Lingua principale
TypeScript
Stelle
97.4k
Fork
6.6k
Merge medio
18h 15m
PR unite (30g)
318

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di microsoft/playwright

Tutte le issue di microsoft/playwright

Issue simili

Altre issue su TypeScript

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.