Build TS con devDeps y runtime solo con deps de produccion, USER node,
healthcheck por proceso (deuda: anadir /healthz), secretos siempre por
entorno/ficheros montados. Imagen verificada con docker build.
Envio de alertas Telegram desde el servicio (docs/legacy-telegram.md): por alerta,
texto Markdown (content + firelink i18n) + ubicacion, como node-red.
- types: canal 'telegram', notif.type 'telegram', campo telegramNotified
- telegram/message.ts: buildTelegramMessages (firelink es/en/gl + location)
- telegram/client.ts: cliente Bot API (fetch), interpretResponse (429 retry_after,
403 blocked)
- telegram/rate.ts: throttle por chat (1 msg/s) + computeWaitMs puro
- handlers.processTelegramJob: idempotencia (notification_sends canal telegram),
modos dry-run/shadow/canary/full, throttle, 429->retry, bloqueo->sub inactiva
- poller/queue/index: canal telegram integrado; worker con rate limiter global
BullMQ (25/s por bot); cliente por idioma (es/gl->ES, en->EN)
- config: bloque telegram (tokens es/en, server, globalPerSec, perChatMinMs)
85 tests en verde, typecheck y build OK. Sin TELEGRAM_TOKEN_* configurados el
worker no se activa (todo inerte). Falta: extraer tokens de bot de flows_cred +
rollout con el usuario. Los flujos conversacionales de los bots siguen en node-red.
El dry-run contra prod destapo 'Error: Custom Id cannot contain :': el jobId era
canal:notificationId. Cambiado a canal_notificationId. Test que lo fija.
mongodb v3.x es CommonJS; el import nombrado ESM (import { MongoClient }) no lo
resuelve el cjs-lexer de Node en runtime (SyntaxError al arrancar dist). Tomo los
valores del default export (mongodb.MongoClient / mongodb.ObjectId). Verificado
importando dist/*.js con node (no solo compilando).
El smoke-test contra prod revelo MongoDB 3.2.11 (EOL): el driver v6 exige >=4.2
y no conecta. Cambios:
- mongodb ^3.7.4 + @types/mongodb; db.ts con useUnifiedTopology, sin retryWrites
- sends.ts: deteccion de duplicate-key (11000) sin depender de MongoServerError
- poller.ts: FilterQuery en vez de Filter
- tests de integracion migrados de mongodb-memory-server a un fake en memoria
(test/fake-repo.ts) porque no hay mongod 3.x ejecutable en hosts modernos;
emula operadores ($ne/$in/$gte/$exists), $set/$unset e indice unico (11000)
- docs: legacy-behavior.md §0 (entorno MongoDB 3.2, sin change streams -> fase
1b usara polling; recomendacion de upgrade de Mongo como fase propia)
47 tests en verde, typecheck y build OK. Datos reales del import: 413 pendientes
FCM, 0 email, 8176 users con fireBaseToken.
Sustituye el envío de push por la API legacy de GCM (muerta desde jun-2024) y
saca el envío del observer de Meteor a una cola BullMQ controlada.
- poller: consume 'notifications' pendientes (campos correctos; el cron viejo
tenía un typo nofitied/emailNofitied que nunca casaba)
- fcm-worker: firebase-admin (FCM HTTP v1), payload compatible con la app
Flutter (FLUTTER_NOTIFICATION_CLICK, collapseKey=_id, data); purga tokens
muertos sin reintentar
- email-worker: nodemailer + plantillas new-fire portadas verbatim
- idempotencia persistente: notification_sends, indice unico (notificationId,
channel) -> sobrevive reinicios y replays
- salvaguardas anti-spam: modos dry-run/shadow/canary/full, exclusion mutua por
canal (OWNED_CHANNELS + notifDisabledChannels en Meteor), kill switch,
limites por usuario/dia y circuit breaker por batch
- docs/legacy-behavior.md (caracterizacion) + docs/rollout.md
- 47 tests (vitest + mongodb-memory-server), typecheck y build OK
- deploy: systemd + pm2 (Node 22 standalone)
Falta el service account de Firebase para envio real de push (pedir al usuario).
