--- name: Cache Dedup + Parallel Search 2026-04-23 description: Gateway dedup, CACHE_TTL 60min padronizado, loop JS paralelo com concorrência 3 type: project originSessionId: bd0e6a03-78da-41ff-b417-686d73a44ae2 --- **Deploy 2026-04-23 ~18:00 UTC** ## Fixes aplicados ### 1. Gateway dedup (pendingSearches) — `/opt/skymilhas/server.js` - **Problema**: frontend disparava requests paralelos com mesma cacheKey → gateway fazia 2 scrapes e salvava cache 2x. Log típico: `(FRESH)` seguido de `(CACHE)` pra mesma data. - **Fix**: novo `Map pendingSearches` (linha ~908). Se cacheKey já tem Promise in-flight, 2ª request aguarda ela terminar e pega cache. - **Backup**: `/opt/skymilhas/server.js.bak-predup-` ### 2. CACHE_TTL padronizado 60min - AA `aadvantage/index.js` + `service.js`: era 120min (2h) → **60min** - Azul `azul/service.js`: era 240min (4h) → **60min** - Todos outros já estavam 60min. Reloads: `scraper-american-aadvantage`, `scraper-azul-tudoazul`. ### 3. Loop JS paralelo — `/var/www/skymilhas/app/Views/painel/index.php` - **Antes**: `for` sequencial `await buscarVoosData(...)` nas N datas → 5 datas × ~15s = ~75s - **Agora**: pool de 3 workers (CONCURRENCIA_DATAS=3) consumindo fila → 5 datas em ~25s - Mantém cancelamento (`buscaCancelada`) e limite atingido (`limiteAtingidoFlag`) funcionando nos workers - UI de progresso atualiza APÓS cada busca concluir (não antes), pois são paralelas - **Backup**: `/var/www/skymilhas/app/Views/painel/index.php.bak-preparallel-` ## Why - Usuário Jesiel reportou que "buscas de vários dias estão demorando" - Cache já funcionava mas tinha race condition (sem dedup) - Loop sequencial era gargalo óbvio ## How to apply - Ganho esperado: 1ª busca fria de 5 dias cai de ~75s para ~25s - 2ª busca mesmas datas (cache hit): <1s (comportamento inalterado) - Se aumentar concorrência além de 3, pode sobrecarregar proxy-seller BR + scrapers (cada data já dispara N subchamadas por companhia) - Se precisar ajustar, editar `CONCURRENCIA_DATAS` no painel/index.php ~linha 36498