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).
30 lines
1.3 KiB
TypeScript
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;
|
|
}
|