egutierrez
f2381b7b2b
Nueve issues nuevos cubriendo deudas tecnicas descubiertas tras ejecutar fn doctor por primera vez: - 0054 deploy_server: reimplementa SSH/systemd/rsync inline en lugar de usar funciones del registry (alta). - 0055 docker_tui: usa docker CLI directo via shell en lugar de docker_* del registry (alta). - 0056 audit_uses_functions: heuristica Python no detecta `from pkg.subpkg import X` (media). - 0057 audit_uses_functions: deteccion de simbolos Go con abreviaturas falla en algunos casos (baja). - 0058 kanban uses_functions sync deferido por WIP en curso (baja). - 0059 doble tracking de apps/*/app.md (fn_registry + sub-repo) inconsistencia (media). - 0060 fn doctor secrets: subcomando para audit secrets en TODOS los repos (media). - 0061 integrar notify_telegram en deploy_server + bucle reactivo (media, depende de 0054). - 0062 politica de deprecacion para 704 funciones sin consumidores (baja, research). Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
80 lines
3.8 KiB
Markdown
80 lines
3.8 KiB
Markdown
# 0061 — Integrar `notify_telegram` en deploy_server + bucle reactivo
|
|
|
|
## APP Metadata
|
|
|
|
| Campo | Valor |
|
|
|-------|-------|
|
|
| **ID** | 0061 |
|
|
| **Estado** | pendiente |
|
|
| **Prioridad** | media |
|
|
| **Tipo** | integration — `apps/deploy_server/`, `fn_operations/` |
|
|
|
|
## Dependencias
|
|
|
|
- `notify_telegram_go_infra` creada el 2026-05-07.
|
|
- `pass` con bot token guardado (`pass insert telegram/bot_token`).
|
|
- `pass` con chat_id (`pass insert telegram/chat_id`).
|
|
- `apps/deploy_server` (issue 0054 paralelo — refactor registry-first).
|
|
- `fn_operations/operations.go::ExecuteAndReact()` (bucle reactivo Go).
|
|
|
|
## Contexto
|
|
|
|
`notify_telegram_go_infra` fue creada como funcion atomica pero no esta integrada en ningun consumidor. El bucle reactivo (`assertions` que fallan) y los deploys (deploy_server) son los dos puntos donde alertas reales tendrian valor inmediato:
|
|
|
|
- **deploy_server**: hoy si un deploy falla solo queda en `deploy_logs`. El usuario tiene que mirar la BD o la TUI para enterarse. Ideal: notify_telegram con `[FAIL] <app>@<host>: <error>`.
|
|
- **bucle reactivo**: assertion `critical` falla → corruption detectada en datos. Hoy solo se persiste en `assertion_results`. Ideal: notify_telegram con `[CRITICAL] <entity>: <rule>: <value> (expected <expected>)`.
|
|
|
|
## Objetivo
|
|
|
|
Anadir hooks de notificacion en los dos puntos:
|
|
|
|
1. `deploy_server` envia notify al final de cada deploy (success o fail).
|
|
2. `fn_operations.ExecuteAndReact` envia notify cuando una assertion `critical` falla.
|
|
|
|
Ambos hooks usan `notify_telegram_go_infra` y leen credenciales de `pass`.
|
|
|
|
## Arquitectura
|
|
|
|
### Archivos afectados
|
|
|
|
- `apps/deploy_server/deployer.go` — anadir post-deploy hook que invoca notify.
|
|
- `apps/deploy_server/app.md` — declarar `notify_telegram_go_infra` en uses_functions.
|
|
- `fn_operations/operations.go` — extender `ExecuteAndReact` con notify hook.
|
|
- `fn_operations/operations_test.go` — test que mockea notify.
|
|
- NUEVA funcion `pass_telegram_creds_bash_infra` o helper Go para leer pass entries.
|
|
|
|
## Tareas
|
|
|
|
### Fase 1 — credenciales desde pass
|
|
1.1 Decidir naming: `pass insert telegram/bot_token` y `pass insert telegram/chat_id`.
|
|
1.2 Helper para leer ambas (existe `pass_get_bash_infra`, basta invocarlo).
|
|
1.3 Documentar setup en `docs/sync_setup.md` (no commitear values).
|
|
|
|
### Fase 2 — integracion deploy_server
|
|
2.1 En `deployer.go` post-deploy: si `deploy_telegram_enabled = true` (config en `deploy_targets`), construir mensaje y llamar `infra.NotifyTelegram(...)`.
|
|
2.2 Truncar mensaje a 4096 chars (la funcion ya lo hace, pero documentar).
|
|
2.3 Schema de `deploy_targets`: anadir columna `notify_telegram BOOLEAN DEFAULT false`.
|
|
2.4 CLI: `deploy_server target add ... --notify-telegram`.
|
|
|
|
### Fase 3 — integracion bucle reactivo
|
|
3.1 En `ExecuteAndReact`, tras evaluar assertions, si alguna `critical` fallo, construir mensaje y llamar notify.
|
|
3.2 Config: `assertion.notify_telegram BOOLEAN` (por assertion) — solo notifica si true.
|
|
3.3 Test `TestExecuteAndReact_NotifiesCriticalFailure` con notify mockeado.
|
|
|
|
### Fase 4 — docs + verificacion
|
|
4.1 Update CHANGELOG.md.
|
|
4.2 Manual test: forzar un deploy fail, verificar mensaje llega.
|
|
4.3 Manual test: forzar assertion fail, verificar mensaje llega.
|
|
|
|
## Riesgos
|
|
|
|
- Spam de notificaciones si una assertion falla repetidamente. Mitigacion: rate limiting (no enviar si ya se envio en ultima hora) — opcional, dejar para v2.
|
|
- Token expuesto en logs si `notify_telegram` lo loggea. Verificar que la funcion redacta el token.
|
|
- Sin pass: la integracion debe degradar silenciosa (log warning, no abortar deploy).
|
|
|
|
## Decisiones de diseno
|
|
|
|
- Mensajes en formato `[<level>] <subject>: <body>` para grep facil en chat.
|
|
- Markdown opcional (parseMode "Markdown") — abre superficie a inyeccion de markdown si el body viene de error externo. Default `parseMode=""` (plain).
|
|
- NO crear topic/thread de Telegram — un solo chat para todo. Si crece, refactor.
|