Investiga causa raiz dos retries entre navegadores

README.md

@@ -241,6 +241,8 @@ No CI, esse relatório é publicado automaticamente no **[GitHub Pages](https://
 
 O projeto roda automaticamente via GitHub Actions (`.github/workflows/tests.yml`) a cada push/PR para a `main` e diariamente às 06:00 UTC. Antes dos testes, o CI valida lint (`eslint`), formatação (`prettier --check`) e tipos (`tsc --noEmit`), quebrando o build se algo estiver fora do padrão. Os cenários rodam em paralelo (`parallel: 4` no `cucumber.js` — cada worker abre seu próprio navegador/contexto isolado, sem estado compartilhado entre eles), reduzindo bastante o tempo total de execução. O relatório HTML, o relatório Allure e os traces de falhas são publicados como artifacts de cada execução; o relatório Allure da `main` também é publicado no GitHub Pages (link no topo deste README). A `main` é protegida: mudanças precisam passar por Pull Request com o check de testes verde. Cenários que falham são reexecutados automaticamente uma vez (`--retry 1`), para absorver instabilidades pontuais de rede sem mascarar bugs reais de código.
 
+> **Investigação real por trás dessa decisão:** rodei a suíte completa 4x em cada navegador, sem retry, pra entender de onde vem a instabilidade de verdade (em vez de só confiar no retry sem questionar). Chromium e WebKit ficaram 100% estáveis nas 4 rodadas cada. O Firefox falhou em 2 das 4, sempre no mesmo passo (`deleteAccount`) — a princípio parecia um bug específico do navegador, mas investigando mais a fundo (reproduzindo repetidas vezes e capturando a página real no momento da falha) descobri que era um erro **520 do Cloudflare** ("Web server is returning an unknown error"), intermitente (~1 em 10 execuções), vindo do próprio automationexercise.com — não é race condition do código nem do navegador. Como é uma falha de infraestrutura de terceiro genuinamente transitória, o `--retry 1` no nível do cenário já é o mecanismo certo pra absorver isso (ele reexecuta o fluxo inteiro, incluindo uma nova navegação, que na prática sempre resolve). Não havia bug de código pra corrigir aqui — a investigação confirmou que a estratégia de retry já em vigor estava correta.
+
 ### Segurança da pipeline
 
 - `npm audit --audit-level=high` roda no CI a cada execução, quebrando o build se houver vulnerabilidade alta/crítica em dependências.

pages/register.page.ts

@@ -67,7 +67,14 @@ export class RegisterPage {
 
   async deleteAccount() {
     await this.page.locator('a[href="/delete_account"]').click();
-    await expect(this.page.getByText('ACCOUNT DELETED!')).toBeVisible();
+    // Esse clique as vezes esbarra num erro 520 transitorio do Cloudflare
+    // na frente do site (investigado a fundo: nao e race condition do
+    // nosso codigo nem especifico de um navegador - a pagina chega a
+    // retornar literalmente "Web server is returning an unknown error").
+    // E raro (~1 em 10 execucoes, nos testes de investigacao) e o
+    // --retry no nivel do cenario (cucumber.js) ja absorve isso, porque
+    // reexecuta o fluxo inteiro, incluindo uma nova navegacao.
+    await expect(this.page.getByText('ACCOUNT DELETED!')).toBeVisible({ timeout: 10000 });
     await this.page.locator('[data-qa="continue-button"]').click();
   }
 }