Sessão caiu

SintomasCopy Anchor Link

• O overview mostra pairingsDegraded acima de zero.
• Em Clientes → Conexões, um canal aparece degraded ou disconnected.
• O responsável recebeu a notificação pairing.disconnected (crítica) ou viu pairing.status com nextRetryAt no app.

ConfirmarCopy Anchor Link

Rotas de admin pedem o token de acesso do backoffice (Authorization: Bearer).

API=https://api.superdinda.com
curl -s "$API/admin/connections?status=degraded" -H "Authorization: Bearer <ADMIN_ACCESS_TOKEN>"
curl -s "$API/admin/seats/<seat-uid>/timeline" -H "Authorization: Bearer <ADMIN_ACCESS_TOKEN>"

1. Na linha do tempo da vaga, procure provider.failed / provider.stopped, seguido de reconnect (uma linha por tentativa).

2. Veja o estado no WAHA, de dentro do container (em produção ele não tem porta pública):

   Copy Text

   docker compose exec waha curl -fsS -H "X-Api-Key: <WAHA_API_KEY>" \
     http://localhost:3000/api/sessions/sd-<pairingUid>

3. Descubra o proxy (coluna proxy em Conexões) e veja quem mais está nele: GET /admin/proxies/<proxy-uid>/bindings. Vários caindo juntos no mesmo endereço apontam para o proxy, não para a sessão.

O que o sistema faz sozinhoCopy Anchor Link

1. FAILED/STOPPED com o pareamento paired → degraded e retry em 30 s.
2. O tick de reconexão (15 s) reinicia a sessão no WAHA; depois 2 min e 10 min.
3. Voltou WORKING → paired, sem nova notificação.
4. Depois da 3ª tentativa: disconnected com ended_at, sessão apagada no WAHA, notificação ao responsável. O binding de proxy da vaga é mantido.

Só os atrasos somam 12 min 30 s (30 s + 2 min + 10 min); o desfecho depende ainda de o WAHA reportar cada falha.

PassosCopy Anchor Link

1. Durante degraded: espere o backoff terminar.

2. disconnected: precisa parear de novo. A pessoa pode fazer pelo próprio link de consentimento (POST /consent-requests/{token}/pairing, código no celular dela) ou o responsável pela tela dele.

3. degraded parado (sem next_retry_at e sem eventos novos): force o fim e peça um novo pareamento. É a ação mais disruptiva que um operador tem; o motivo é obrigatório e fica na auditoria.

   Copy Text

   curl -s -X POST "$API/admin/seats/<seat-uid>/pairing/reset" \
     -H "Authorization: Bearer <ADMIN_ACCESS_TOKEN>" -H "Content-Type: application/json" \
     -d '{"reason":"degraded sem retry após restart sem resposta"}'

Quando escalarCopy Anchor Link

• Várias sessões do mesmo endereço → Proxy queimado.
• Todas as sessões ao mesmo tempo → WAHA fora do ar.
• O mesmo número cai de novo logo depois de parear, ou não consegue parear → Número banido.

FontesCopy Anchor Link

• backend/src/domains/channels/use-cases/{apply-provider-state,cancel-pairing}.ts, backend/apps/workers/reconnect-ticker.ts
• backend/src/http/routes/admin/{operator-lists,proxies}.route.ts, backend/src/domains/insights/use-cases/{operator-lists,seat-timeline,overview}.ts
• backend/src/config/env.ts (WABA_RECONNECT_TEMPLATE), backend/docker-compose.prod.yml
• Vault: AD-010, AD-016