id: "REQ-282" title: "Estabilização determinística do teste de retry assíncrono em XHR no global-csrf-refresh (Vitest)" status: "complete" date: "2026-10-16" author: "architect" target_repo: "conn2flow" batch: "BATCH-291" topology: "solo" autonomy: "autonomo_monitorado" release: "gestor-v3.0.8"
req-282: Estabilização de temporização assíncrona em XHR no teste de CSRF
Ocorrência / Relato
Na execução do pipeline de CI do release (release-gestor.yml), o teste unitário de frontend em tests/Unit/JS/global-csrf-refresh.test.js falhou com:
AssertionError: expected [ [ 'POST', '/site/admin-arquivos/' ] ] to have a length of 2 but got 1 (linha 457).
Diagnóstico
Em tests/Unit/JS/global-csrf-refresh.test.js, o método xhrRepetirComNovoToken(xhr) dentro de gestor/assets/global/global.js renova o CSRF de forma assíncrona via fetchNativo e, após a resolução da Promise, agenda o reenvio via setTimeout(..., 0).
O teste utilizava um await esperar() com tempo fixo de apenas 5 ms (ms = 5). Em ambientes de runner compartilhado (como GitHub Actions em Ubuntu com execução concorrente de múltiplos workers e 700 testes simultâneos), 5 ms é insuficiente para garantir a execução do ciclo de microtarefas e da macrotarefa do timer. Como consequência, o teste asseria a segunda abertura (xhr.aberturas.length === 2) antes do setTimeout ser disparado pelo event loop.
Resolução
-
Substituição de asserções pós-espera por
await vi.waitFor(...)nos testes de ciclo de vida assíncrono de XHR (tests/Unit/JS/global-csrf-refresh.test.js), garantindo que o Vitest aguarde de forma determinística e reativa a resolução da segunda abertura e dos disparos de eventos. -
Elevação defensiva do tempo padrão do helper
esperar(ms = 50)para evitar condições de corrida em asserções temporizadas. -
Validação local completa da suíte: 63 arquivos de teste, 700/700 testes aprovados.