E2E flake — C113 (feed vivo) falha sob 4 workers: feed global + not.toContain colide com atividade de worker paralelo às 11:00 #122
Loading…
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Débito registrado no fechamento da #113 (capture-review-debts autônomo, 2026-08-20) após o verify do deploy falhar 1x no e2e full.
Sintoma
tests/e2e/campaignAgendaFeed.e2e.spec.ts:119(C113 "serves a live feed") falha (3 tentativas) no e2e full com 4 workers, mas passa no run isolado/retry. Erro:expect(received).not.toContain("DTSTART:20260819T140000Z")— o feed retornado contém o DTSTART 14:00Z de uma atividade "Comício na agenda--4" (título do fixture de OUTRO spec, ex. campaignActivity) criada por um worker paralelo às 11:00 de hoje — a mesma hora dostartAtBoriginal da C113 (que é editado para 12:00). O feed vivo é global (todas as atividades confirmadas da campanha), a DB de e2e é compartilhada entre os 4 workers → o assertnot.toContaincolide com atividades alheias no mesmo dia/horário.Causa
/campanha/agenda/ical/<slug>sem escopo por município/autor → qualquer teste que crie atividade "confirmado" às 11:00 (14:00Z) do dia atual polui a C113.Correção candidata (a decidir no item)
createdBy), de modo que atividades de outros workers não entrem.not.toContain(horário)paranot.toContain(UID)da atividade B — UIDs são únicos por spec).Nota: o verify do deploy é a suíte full com 4 workers; flake como esse bloqueia dispatches de forma probabilística (1 falha em 2 runs na mesma noite).
Escopo
tests/e2e/campaignAgendaFeed.e2e.spec.ts(+ helpers de fixture, se preciso).Atualização após o 2º verify falho (run 32321780616, mesmo SHA
6cf5ea58): desta vez o C113 passou (2.3s) e falharamcampaignLeadershipsB34 (chips,toHaveAttributelink 'Aurelino Leal' não encontrado, 3 tentativas), B32 (auto-save, 1.0m — falhou também no 1º run) ecampaignMunicipalities:382(B176, filtros, 1.0m). Padrão comum aos 2 runs: timeouts de 60–90s em specs de UI de listas (lideranças/municípios) sob 4 workers, com o webServer processando PATCHes devagar. Nenhuma regressão de código: o verify do mesmo fluxo passou full às 01:13 com SHA02c1e4f3(mesmo runtime do6cf5ea58— o delta é docs/CI). Re-dispatch é o caminho do runbook; se o flake persistir em runs seguidos, vale investigar carga do runner hosted (2 vCPU) vs. 4 workers.3º verify falho (run 32330313520, SHA
aeb33eb4— agora inclui feat(S8)/feat(S9)/refactor(S11), runtime real): specscampaignSavedFilters:26(strict mode violation —getByRole('link', { name: 'Municípios' })resolveu para 2 elementos, 3x),admin:138(login.ok() === falseno login do admin, 1.3s),campaignContacts:171(dialog 'Novo contato' visível quando esperava hidden, 2x),campaignMunicipalities:638/859(2x/1x). Espalhamento maior do que timing puro: 3 runs falhos em 4, specs diferentes, com 1 full verde no meio (01:13, SHA02c1e4f3). Hipóteses para o item: (a) carga do runner hosted (2 vCPU) vs. 4 workers + webServer Next + Payload + Postgres; (b) o spec S11 novo (admin:138Instagram sync) pode ter ficado sensível a estado do global social-feed-settings no seed; (c) strict-mode do sidebar pode ser estado induzido por spec anterior (filtros salvos deixam o menu expandido). Proposta: rodar o full com 2 workers como teste (se estabiliza, é CPU; senão, são os specs), ou investigar o S11 antes do próximo deploy.Síntese após o 4º verify falho (run 32332230751): as falhas têm causas mapeadas e a suíte full sob 4 workers está probabilisticamente vermelha (~20% de sucesso em 5 runs na noite).
campaignMunicipalities:638— falhou nos runs 1, 3 e 4 (recorrente).campaignSavedFilters:26— strict mode violation:getByRole('link', { name: 'Municípios' })resolve 2 elementos (sidebardata-sidebar="menu-button"+ bottom nav mobiletext-[10px]) quando o drawer do sidebar está aberto + bottom nav visível; o locator é sem escopo e o próprio spec admite flake conhecido com >1 worker no comentário do arquivo.admin:138—login.ok() === false: colisão do login do usuário de teste em paralelo — causa conhecida na Issue #116 (unificar logins com advisory lock).campaignContacts:171,campaignDemandVisibility,campaignPeople(C117/C125),campaignSollinhaContext,campaignMunicipalities:1510— timeouts/estados com retry resolvendo em parte.Recomendação para destravar o deploy: resolver #116 (advisory lock do login) + escopar o locator do savedFilters antes do próximo dispatch, OU rodar o full com 2 workers como medida temporária. O runner self-hosted em si está validado — o job deploy pegou o runner em todos os 5 runs e executou o
deploy-homeserver.shcom os guards corretos (stale-run idempotente); o que falta é apenas 1 verify verde.Tracker migrado para o GitHub — continue em #gh763 (github.com/fsolla/teqo/issues/763). Esta Issue Forgejo está fechada.