Repository navigation
Investiga causa raiz dos retries entre navegadores - #66
Merged
Merged
Conversation
Rodei a suite completa 4x em cada navegador, sem retry, pra entender de onde vem a instabilidade de verdade em vez de so confiar no retry sem questionar. Chromium e WebKit: 100% estaveis (4/4 cada). Firefox: falhou em 2 das 4, sempre no mesmo passo (RegisterPage.deleteAccount). Investigando mais a fundo (reproducao repetida + captura da pagina real no momento da falha), descobri que nao e race condition do codigo nem bug especifico do Firefox - e um erro 520 transitorio do Cloudflare vindo do proprio automationexercise.com (~1 em 10 execucoes na investigacao). Como e falha de infraestrutura de terceiro genuinamente transitoria, o --retry 1 ja existente no nivel do cenario e o mecanismo certo pra absorver isso. Nao havia bug de codigo pra corrigir - a investigacao confirmou que a estrategia de retry em vigor estava correta, e documentei o achado no README. Mantido um ajuste pequeno e honesto: o timeout da asserção de conta deletada subiu de 5s (padrao do Playwright) pra 10s, como margem geral de seguranca - nao e a causa raiz, mas e inofensivo manter.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Resumo
Ultimo item da lista de melhorias: investigar de verdade a causa raiz das falhas que o
--retry 1absorve, em vez de so confiar nele sem questionar (conexao direta com uma reflexao sobre testes 'sempre verdes' que tivemos numa conversa anterior).Metodologia
Rodei a suite completa 4x em cada navegador, sem retry, pra ver a taxa de falha real sem o retry mascarando nada:
RegisterPage.deleteAccount)Investigacao mais a fundo
A principio parecia um bug especifico do Firefox (race condition, na linha do que ja encontramos antes com WebKit no login). Testei a hipotese de contencao de recursos (rodando sequencial,
--parallel 1) e ainda falhava ~50% das vezes no mesmo passo — entao nao era so concorrencia.Reproduzindo repetidamente e capturando o estado real da pagina no momento exato da falha, descobri a causa verdadeira: um erro 520 do Cloudflare ("Web server is returning an unknown error"), vindo do proprio automationexercise.com, intermitente (~1 em 10 execucoes na investigacao mais extensa). Nao e race condition do nosso codigo nem bug especifico de navegador — e infraestrutura de terceiro genuinamente instavel.
Conclusao
Como e uma falha transitoria real do servidor de terceiro, o
--retry 1ja existente no nivel do cenario (cucumber.js) e o mecanismo certo pra absorver isso — ele reexecuta o fluxo inteiro, incluindo uma nova navegacao, e na pratica sempre resolve. Nao havia bug de codigo pra corrigir aqui. Documentei o achado completo no README, ligado a explicacao que ja existia sobre o--retry 1.Mantive um ajuste pequeno e honesto: a asercao de "conta deletada" teve o timeout aumentado de 5s (padrao do Playwright) pra 10s, como margem geral de seguranca — nao e a causa raiz (um erro 520 nao desaparece esperando mais), mas e inofensivo manter como timeout um pouco mais generoso pra essa etapa especifica (unica no projeto que envolve uma navegacao real de pagina, nao so atualizacao de DOM).
Test plan
npm run lintnpm run format:checknpm run typecheck--retry 1), todos verdes