Files
b2bcall/apps/dialer-worker/src/callback-sweep.ts
B2BCall Bootstrap 80e72881b2 feat: Fase 9/10 — métricas, scripts operacionais, callback/wrap-up e aceite final
Fase 9 (segurança e produção):
- GET /api/metrics: endpoint Prometheus com métricas reais (chamadas,
  agentes, filas, CPS por campanha), protegido por permissão
- scripts/backup.sh, restore.sh, healthcheck.sh, install.sh, update.sh —
  testados contra o ambiente real (backup.sh e healthcheck.sh rodados de
  verdade; install.sh/update.sh validados por inspeção, ambiente atual já
  provisionado)
- POST /api/agent-console/dispose: aplica disposição de chamada de verdade
  (lacuna deixada aberta desde a Fase 6), com ações CALLBACK (agenda
  retorno) e DO_NOT_CALL (suprime automaticamente)
- apps/dialer-worker/src/callback-sweep.ts: reativa leads com callback
  vencido; GET /api/callbacks para consulta
- apps/dialer-worker/src/wrap-up-sweep.ts: transição automática
  WRAP_UP -> AVAILABLE + despausa real na fila do Asterisk. Exigiu corrigir
  main.ts para conectar ao AMI mesmo em DIALER_SIMULATION=true
  (DIALER_SIMULATION deve impedir só originação de chamada, não ações
  administrativas de fila)
- nftables revisado (sem alterações necessárias)
- Documentação completa: INSTALL, OPERATIONS, BACKUP_RESTORE, SECURITY,
  DATABASE, API, ASTERISK, OPENSIPS (não implementado, motivo
  documentado), TROUBLESHOOTING
- README.md e CHANGELOG.md reescritos

Fase 10 (testes e aceite):
- Quality gate completo executado: build/typecheck (7 workspaces), lint,
  46 testes unitários, docker compose config/ps, healthcheck — tudo verde
- Aceite de segurança (seção 92): 13 itens verificados ao vivo contra o
  sistema real, não só por inspeção de código
- Aceite Asterisk (seção 93): os 5 comandos executados e documentados,
  comunicação API->AMI->Asterisk validada
- docs/RELATORIO_FINAL.md: relatório final no formato da seção 96

Todos os fixtures de teste desta fase foram removidos/desativados ao
final. Credenciais de acesso entregues separadamente em CREDENCIAIS.txt
(fora do git, nunca versionado).
2026-08-27 19:16:14 -03:00

30 lines
1.3 KiB
TypeScript

import { PrismaClient } from '@b2bcall/database';
import { logger } from './logger';
// Ativa callbacks agendados (agente.md seção 41) cujo horário chegou. O
// lead fica em status CALLBACK enquanto aguarda (não elegível para
// discagem — ver lead-repository.ts, que só reserva READY/BUSY/NO_ANSWER/
// FAILED); ao vencer, volta para READY com next_attempt_at = agora, mesmo
// caminho de qualquer retry normal. "completed" aqui significa "já foi
// reenfileirado para discagem", não "a ligação de retorno aconteceu" — isso
// é registrado depois via nova disposição, como qualquer outra tentativa.
export async function activateDueCallbacks(prisma: PrismaClient): Promise<number> {
const due = await prisma.callback.findMany({
where: { completed: false, scheduledAt: { lte: new Date() } },
});
if (due.length === 0) return 0;
for (const callback of due) {
await prisma.$transaction([
prisma.lead.updateMany({
where: { id: callback.leadId, status: 'CALLBACK' },
data: { status: 'READY', nextAttemptAt: new Date() },
}),
prisma.callback.update({ where: { id: callback.id }, data: { completed: true } }),
]);
}
logger.info({ count: due.length }, 'Callbacks vencidos reativados para discagem');
return due.length;
}