relay: imagen de 2026-08-25 — el semáforo de handlers se llenó y por WebSocket no salió ningún mensaje durante 24 h #11

Context

Del 2026-10-16 ~11:56 al 2026-10-17 12:17 (Lima) nadie pudo enviar desde Buzz Desktop ni desde el móvil: el envío daba "error de conexión" al minuto. Leer sí funcionaba (va por POST /query del bridge HTTP), y los envíos por HTTP (buzz CLI) también.

Causa medida: el relay corre ghcr.io/block/buzz:sha-52621c0 (2026-08-25, la de Desktop 0.5.20) según deploy/railway/Dockerfile en railway-deploy. Los clientes están en Desktop 0.5.28. Upstream va 451 commits adelante (95 en crates/buzz-relay/buzz-pubsub).

En esa versión, crates/buzz-relay/src/connection.rs:571 toma un permiso de handler_semaphore (global, en memoria, BUZZ_MAX_CONCURRENT_HANDLERS default 1024) por cada EVENT/REQ/COUNT y lo suelta solo cuando el handler termina. handlers/req.rs no tiene deadline. Con los 1024 permisos tomados, todo EVENT por WebSocket recibe NOTICE "rate-limited: too many concurrent requests" y nunca un OK; el cliente espera el OK y corta a los 60 s. El relay no loguea ese rechazo, así que los logs se veían limpios.

Upstream lo cerró en block#7854 (2026-09-28, 9b1c4f98e): "a 188-reply thread never finishes" → statement_timeout de 20 s en las lecturas aux, timeout terminal para REQ/COUNT y lifecycle de suscripciones bajo un solo lock (los refcounts de topics; tenemos ~58 warns/min de release_topic called for unretained topic). <> que la consulta colgada fuera exactamente esa: no hay acceso a las métricas internas (puerto 9102).

Mitigación aplicada 2026-10-17 12:17: deploymentRestart del relay (vacía el semáforo). Sin el update, se vuelve a llenar.

Proposed fix

1. Backup de postgres-volume y minio-volume antes de tocar nada (volumeInstanceBackupCreate; IDs en handbook/infrastructure/railway.md §buzz). Verificar el backup con volumeInstanceBackupList, no con el booleano de la mutación.
2. En cofoundy/buzz@railway-deploy, cambiar ARG BUZZ_IMAGE=ghcr.io/block/buzz:sha-52621c0 a un sha-<commit> de upstream main que sea ≥ 9b1c4f98e y cuyo tag exista en ghcr (<> cuál es el último tag publicado). Nunca :latest.
3. Leer antes las 28 migraciones de crates/buzz-db entre 52621c0..<sha> y los cambios de config (NIP-FI shadow mode df3f28a2c, mesh JWKS 2d0f78c6e, operator listeners ebe99a46e que hace fallar el arranque con config inválida) y decidir qué env vars hacen falta.
4. PR a railway-deploy; el deploy a prod lo aprueba André.

Acceptance criteria

• Backups de volumen de postgres y minio con fecha del día, verificados por listado.
• El relay corre una imagen sha-* ≥ 9b1c4f98e (verificado contra la API de Railway, no contra el Dockerfile).
• La sonda por WebSocket (abajo) devuelve OK true en < 2 s.
• Desktop 0.5.28 y móvil envían y reciben en un canal y en un DM.
• Huddle, git (buzz repos) y media (subir una imagen) siguen funcionando.
• handbook/infrastructure/SYSTEMS.md §Buzz y buzz/BITACORA.md dicen la imagen nueva y la fecha.

Verification method — OBSERVED

Sonda: abrir wss://buzz.cofoundy.dev, responder el AUTH de NIP-42 con la llave -cc y mandar un kind 9 con ["h","32fd4fb9-3ab1-447c-b000-aafc4a8e7934"] (#pilot-agentes). Script: un websockets + coincurve de ~40 líneas (handshake, sign_schnorr).

Antes del restart (2026-10-17 11:47, Mac de André):

[  0.8s] <- ["AUTH","4f76e9c4…"]
[  1.0s] <- ["OK","a389b497…",true,""]
[  1.0s] -> EVENT 3929b47354340677
[  1.2s] <- ["NOTICE","rate-limited: too many concurrent requests"]
[ 71.2s] SIN OK del relay en 70s

Después del restart (12:18):

[  0.9s] -> EVENT 62a2af58101d2c44
[  1.1s] <- ["OK","62a2af58…",true,""]

Después del update se espera lo segundo.

Guardrails

• No borrar ni recrear volúmenes (el 2026-08-04 eso dejó 42 h de caída).
• No usar :latest. No usar railway up (el servicio tiene source de GitHub).
• No mergear ni desplegar sin el OK de André: es prod y las migraciones no tienen vuelta atrás salvo restaurar el backup.
• No tocar BUZZ_MAX_CONCURRENT_HANDLERS como "fix": subirlo solo tarda más en llenarse.

Scope + references

Una sola cosa: actualizar la imagen del relay. El monitoreo va en un issue aparte.

• deploy/railway/Dockerfile (rama railway-deploy)
• Railway: proyecto 2d577330-c1ed-4ace-9005-9ec7c31f3f44, relay dcd8a136-906e-4c63-9793-0987b887c55e
• upstream 🤖 perf: bound long-thread aux reads and make query deadlines terminal block/buzz#7854, Hosted relay: write path 500 / DB pool timeout; accepted DM events not fanned out; WS subscription silently stops delivering block/buzz#4743 (síntoma parecido en el relay hosteado)
• handbook/infrastructure/buzz/BITACORA.md, handbook/infrastructure/railway.md §buzz