Actualización de Entergram - Semana del 25 de junio de 2026: estabilidad, herramientas de proxy y más de 25 correcciones

Esta fue una semana de ingeniería profunda en Entergram. Lanzamos dos funciones nuevas de infraestructura, mejoramos de forma notable la estabilidad para espacios de trabajo con mucho volumen y cerramos más de 25 errores repartidos entre mensajería, gestión de conexiones, onboarding, facturación y la tabla del CRM. Esto es todo lo que entró.

Los administradores ya pueden atribuir el tráfico de proxy a rutas y cuentas conectadas concretas, lo que da visibilidad sobre qué conexiones consumen más ancho de banda. Junto con eso, ahora puedes asignar proxies estáticos dedicados a rutas individuales, algo útil cuando necesitas una IP predecible y estable para cuentas de Telegram específicas en lugar de dejar que el pool rote.

DEV-149 en Linear

Un worker en segundo plano sondea ahora cada proxy de forma periódica y actualiza su estado de salud. Esto significa que el panel de administración refleja el estado real de conectividad, así que puedes detectar proxies degradados antes de que afecten en silencio a tus usuarios, en vez de enterarte por un ticket de soporte.

DEV-151 en Linear

Para equipos que operan decenas de cuentas personales, estas dos piezas van juntas. Cada cuenta conectada en Entergram se enruta por su propio proxy único, y esa separación es justo lo que mantiene las cuentas sanas cuando el volumen crece. Hasta ahora la salud del proxy era algo que solo se notaba cuando fallaba. Ahora es un dato observable: ves qué ruta consume, qué ruta está degradada y qué cuenta conviene mover a una IP estática antes de que alguien note una lentitud.

Los espacios de trabajo grandes, aquellos con cientos de chats repartidos entre muchas cuentas conectadas, sufrían bloqueos importantes del hilo principal y lentitud en el navegador. Esta semana reformamos el motor de conexión ws-v2 para limitar las ráfagas de account.bind y espaciar las llamadas a folder.chats.fetch. El resultado: una sesión de QA que antes producía 692 tareas largas y unos 166 segundos de bloqueo del hilo principal ahora carga de forma limpia.

DEV-191 en Linear

Vale la pena detenerse en el número. 166 segundos de bloqueo acumulado no significa que la app estuviera caída casi tres minutos; significa que durante la carga inicial el navegador dejaba de responder en tramos cortos y constantes. Es el tipo de degradación que no aparece en ningún registro de errores porque técnicamente nada falla. Simplemente el equipo siente que "la herramienta va lenta" y nadie sabe explicar por qué. Ese es exactamente el problema que resuelve esta entrega.

Las cuentas en espacios de trabajo con mucha actividad mostraban insignias de "Reconexión necesaria / Desconectado" incluso cuando la sesión MTProto del backend estaba viva y sirviendo tráfico. Los operadores que pulsaban Reconectar provocaban reinicios de sesión innecesarios y, en algunos casos, llegaban a los límites de FLOOD_WAIT de Telegram sobre el número de teléfono. La insignia ahora solo aparece cuando hay un problema real de conexión.

DEV-177 en Linear

Este era uno de esos errores cuyo coste real estaba fuera del producto. Una insignia falsa lleva a una acción humana razonable (reconectar) que sí tiene consecuencias reales en Telegram. Desacoplar el indicador visual del estado de la conexión evita toda esa cadena.

Los mensajes de audio vuelven a reproducirse. Los mensajes de voz entrantes fallaban en silencio: el botón de reproducir no hacía nada. Corregido en todos los tipos de chat. (DEV-133)

Resueltos los errores de "Socket closed". Varios espacios de trabajo sufrían desconexiones duras con un error de contexto en chat.subscribe. La lógica de reconexión del socket ya es estable. (DEV-120)

El historial de supergrupos y canales carga correctamente. Navegar por supergrupos disparaba errores de "Invalid realtime command payload" en la ruta history.around cuando el frontend enviaba pistas de peer (entity_class_name) que el gateway no reconocía. Corregido en la capa del gateway. (DEV-168, PRODUCT-121)

La página ya no se congela al chatear o reenviar. Queda resuelta una familia de bloqueos que obligaban a recargar y que afectaban a operadores en plena conversación. (DEV-143)

El estado en línea es consistente. El indicador de presencia de la tabla de chats y el de la cabecera del chat leían de fuentes distintas. Ahora comparten un único estado de presencia resuelto. (DEV-186)

Nombres de remitente correctos en chats grupales. Las burbujas de mensaje en hilos de grupo mostraban a veces un nombre de usuario de Telegram equivocado sobre el contenido. Corregido tanto en la ruta chat_list.window.snapshot como en live_chat_list.delta. (DEV-192)

Los contadores de no leídos se mantienen exactos. Varios escenarios hacían que la insignia contara de más; por ejemplo, enviabas 2 mensajes y aparecían 5 como no leídos. El contador ahora se reconcilia correctamente entre reconexiones. (DEV-135)

Corregidas las burbujas de mensaje duplicadas. Cuando dos o más cuentas conectadas compartían el mismo chat, el mismo mensaje podía aparecer dos veces en el hilo abierto. Era un problema de deduplicación en el renderizado del frontend, no un fallo de fusión entre cuentas. Corregido. (DEV-183)

Resueltos el remitente de reserva y los actores de reacciones. El historial mostraba a veces other como etiqueta del remitente en mensajes entrantes, y los popovers de reacciones se quedaban en "Cargando reacciones". Ambos corregidos. (DEV-156)

Los chats permanecen en la vista de carpeta después de responder. Las carpetas con la opción "Excluir chats leídos" expulsaban el chat en cuanto el operador enviaba una respuesta, con lo que la conversación desaparecía a mitad de sesión. Ahora las carpetas conservan los chats respondidos hasta que sales de la vista. (DEV-178)

El MCP puede escribir a contactos nuevos. La integración de MCP daba error al intentar enviar un mensaje a un contacto de Telegram con el que nunca habías hablado antes. Los primeros envíos ya funcionan correctamente. (DEV-141)

Las sesiones muertas se recuperan solas. Un fallo en la lógica de capacidad de rutas del agente de sesiones (observeRoutes) hacía que algunas sesiones dejaran de reiniciarse tras caer. Las cuentas afectadas mostraban nats: no responders en cada petición de historial o de carpeta, y reiniciar el agente no ayudaba. El problema de inanición está resuelto y las sesiones muertas vuelven a revivir. (DEV-139)

El diálogo de conexión de ws-v2 ya no inunda de errores 400. Un problema de sincronización hacía que el bucle de sondeo de conexión de cuenta siguiera consultando un ID de sesión de autenticación inexistente, produciendo cientos de avisos de API request failed: 400 en una sola sesión. Corregido en el ciclo de vida del sondeo. (DEV-181)

El estado de conexión del proxy se muestra bien en Ajustes. El indicador de proxy se quedaba en "cargando" al visitar la página de Ajustes, incluso con conexiones sanas. Ahora refleja el estado real en vivo. (DEV-154)

Los usuarios pueden unirse a los espacios de trabajo de forma fiable. Un fallo de React por profundidad máxima de actualización (#185) se disparaba cada vez que un usuario nuevo llegaba a la tabla de chats del CRM tras unirse. La causa raíz era una referencia de array reinstanciada constantemente dentro de la definición de CHAT_PAGE_SIZE_OPTIONS; ahora vive fuera del ciclo de renderizado. (DEV-165, DEV-167)

Corregida la aceptación de invitaciones en el onboarding. Los usuarios que pegaban un enlace de invitación durante el onboarding podían completar el flujo sin unirse de verdad al espacio de trabajo destino, quedándose en un espacio personal vacío y provocando un fallo al navegar a Ajustes → Tabla de chats. La lógica de aceptación y redirección ya es correcta. (DEV-170)

Los usuarios eliminados ya no reaparecen. Los miembros que habían sido eliminados o que se habían ido volvían a entrar en cada recarga a través de una sesión antigua del enlace de invitación. El endpoint /api/onboarding ahora comprueba el estado de membresía antes de volver a unir a nadie. (DEV-175)

Esta última corrección importa más de lo que parece si gestionas controles de privacidad y permisos dentro del espacio de trabajo. Un usuario dado de baja que vuelve a aparecer solo es un incordio operativo; también es una brecha de acceso. Ahora la pertenencia se comprueba en el servidor en cada intento.

Se pueden cancelar las solicitudes de cambio de correo. El botón de cancelar de un cambio de correo pendiente no estaba conectado a ninguna acción: al pulsarlo no ocurría nada. Ahora cancela correctamente la solicitud. (DEV-137)

La selección de chats en tema claro es visible. Seleccionar filas de chat en el tema blanco producía resaltados invisibles o casi invisibles por un token de contraste ausente. Corregido. (DEV-157)

Los propietarios en prueba pueden comprar asientos sin encontrarse un callejón sin salida. Llamar a purchaseSeat() antes de que el propietario tenga una suscripción de pago activa devuelve 400 OWNER_SUBSCRIPTION_REQUIRED. Los propietarios en prueba ahora ven un aviso claro para suscribirse primero, con una ruta directa a la página de suscripción. (DEV-174)

Las compras de suscripción funcionan de forma fiable. Queda resuelta una familia de conflictos de autenticación 401/403 en el checkout, provocados por la invalidación de sesión durante la redirección a Stripe. (DEV-172)

El multimedia y el vídeo se reproducen sin errores de límite de tasa. El endpoint /api/realtime/media estaba sujeto a un limitador genérico de 20 peticiones por minuto. La reproducción de vídeo en el navegador emite varias peticiones de rango de bytes sobre el mismo archivo, lo que agotaba el límite en menos de un segundo. Las peticiones de multimedia ahora no pasan por ese limitador genérico. (DEV-152)

La búsqueda es completa y consistente. Algunas búsquedas devolvían resultados parciales o fallaban con "Telegram Search is unavailable" en la primera consulta, mientras que las búsquedas siguientes del mismo término sí funcionaban. Corregido: los resultados llegan bien desde la primera petición. (DEV-136)

"Tiempo desde el primer mensaje entrante" cuenta desde Telegram, no desde que abres la app. Esta columna especial arrancaba el reloj en el momento en que abrías Entergram, en lugar de cuando Telegram recibió el mensaje por primera vez. La fuente de la marca de tiempo ya es correcta. (DEV-162)

Si resumimos las 25 correcciones en una sola idea, es esta: el producto tiene que ser aburrido en la capa de transporte para poder ser útil en la capa de negocio. Un operador que gestiona 300 conversaciones desde varias cuentas personales no puede permitirse dudar de si un contador de no leídos es real, si un mensaje se envió dos veces o si la insignia de desconexión significa algo. Cada uno de esos pequeños fallos de confianza obliga a comprobar manualmente, y comprobar manualmente es exactamente el trabajo que un CRM de Telegram existe para eliminar.

Tres recomendaciones prácticas tras esta entrega:

1. Revisa tus rutas de proxy. Si tienes cuentas críticas (las que llevan tus clientes más grandes), considera asignarles un proxy estático dedicado ahora que puedes hacerlo por ruta.
2. Vuelve a probar tus carpetas. Con la corrección de "Excluir chats leídos", los flujos de trabajo basados en carpetas que habías abandonado por molestos vuelven a ser viables.
3. Si usas el MCP, prueba los primeros envíos. Escribir a un contacto con el que nunca habías hablado ya funciona, lo que abre flujos de prospección que antes fallaban en silencio.

Seguimos publicando notas de versión cada dos semanas y leemos todos los informes de error que llegan por el canal de soporte. Buena parte de lo que aparece en esta lista entró porque alguien se tomó el tiempo de describir exactamente qué hizo antes de que algo se rompiera. Eso ahorra días de reproducción, así que gracias.

El registro completo de la v0.16.0 y de todas las versiones anteriores está disponible en la página de Novedades de Entergram.