AiHummer está diseñado para completar una respuesta incluso cuando la conexión de un canal se interrumpe brevemente o la instancia se reinicia. Esta página describe la comportamiento visible y las acciones que un administrador debería tomar. Intencionalmente no requiere que comprendas la maquinaria interna de entrega de la plataforma.
Lo que los usuarios deberían ver
Después de que un usuario envía un mensaje:
La sesión muestra el mensaje que fue aceptado.
El agente lo procesa y produce una respuesta visible.
Si el canal está temporalmente no disponible, se vuelve a intentar la entrega.
Cuando el canal vuelve, la respuesta aparece sin que el usuario tenga que enviar
la misma solicitud de nuevo.
La misma solicitud no debería producir respuestas visibles duplicadas. Si un cliente se reconecta, puede recargar el historial reciente, pero la conversación en sí sigue siendo una sesión continua.
Qué sucede después de un reinicio
Una actualización de instancia, un reinicio del host o un reinicio inesperado no deberían hacer que una solicitud aceptada desaparezca. El trabajo que puede continuar de manera segura se reanuda después de que la instancia se vuelve saludable. El usuario debería ver ya sea la respuesta completada o un estado de fallo claro que se pueda reintentar.
[!NOTE]
No repita inmediatamente una solicitud mientras la instancia aún se está recuperando.
Primero espera a que el estado de salud vuelva a la normalidad y actualiza la sesión.
Esto evita crear una solicitud realmente nueva junto con la que se está recuperando.
Si no llega una respuesta
Abrir Estado y confirme que la instancia y el canal afectado son
saludable.
Abre la sesión y actualízala una vez.
Revisar Notificaciones para una advertencia de entrega o de canal.
Envía un nuevo mensaje de prueba corto solo después de que la solicitud anterior sea visible
resultado de éxito o fracaso.
Si el problema se repite, registre la hora, la sesión, el canal y el error visible,
entonces contacta al soporte. Nunca pegues claves API o secretos de canal en un ticket.
AiHummer está diseñado para completar una respuesta incluso cuando la conexión de un canal se interrumpe brevemente o la instancia se reinicia. Esta página describe la **comportamiento visible** y las acciones que un administrador debería tomar. Intencionalmente no requiere que comprendas la maquinaria interna de entrega de la plataforma.
## Lo que los usuarios deberían ver
Después de que un usuario envía un mensaje:
1. La sesión muestra el mensaje que fue aceptado.
2. El agente lo procesa y produce una respuesta visible.
3. Si el canal está temporalmente no disponible, se vuelve a intentar la entrega.
4. Cuando el canal vuelve, la respuesta aparece sin que el usuario tenga que enviar
la misma solicitud de nuevo.
La misma solicitud no debería producir respuestas visibles duplicadas. Si un cliente se reconecta, puede recargar el historial reciente, pero la conversación en sí sigue siendo una sesión continua.
## Qué sucede después de un reinicio
Una actualización de instancia, un reinicio del host o un reinicio inesperado no deberían hacer que una solicitud aceptada desaparezca. El trabajo que puede continuar de manera segura se reanuda después de que la instancia se vuelve saludable. El usuario debería ver ya sea la respuesta completada o un estado de fallo claro que se pueda reintentar.
> [!NOTE]
> No repita inmediatamente una solicitud mientras la instancia aún se está recuperando.
> Primero espera a que el estado de salud vuelva a la normalidad y actualiza la sesión.
> Esto evita crear una solicitud realmente nueva junto con la que se está recuperando.
## Si no llega una respuesta
1. Abrir **Estado** y confirme que la instancia y el canal afectado son
saludable.
2. Abre la sesión y actualízala una vez.
3. Revisar **Notificaciones** para una advertencia de entrega o de canal.
4. Envía un nuevo mensaje de prueba corto solo después de que la solicitud anterior sea visible
resultado de éxito o fracaso.
5. Si el problema se repite, registre la hora, la sesión, el canal y el error visible,
entonces contacta al soporte. Nunca pegues claves API o secretos de canal en un ticket.
Para la recuperación específica de canales, abra la guía correspondiente en [Canales](/es/v1.0/webui/channels). Por ejemplo, chequeos de salud, ver [Systemd y comprobaciones de estado](/es/v1.0/operations/systemd-health).
## Qué deben supervisar los administradores
Observe los resultados visibles para el usuario en lugar de los detalles de implementación:
- las respuestas dejan de llegar a un canal mientras otros canales funcionan;
- las sesiones permanecen en curso durante un tiempo inusualmente largo;
- la instancia cambia repetidamente entre saludable e inactiva;
- las notificaciones informan fallos de entrega repetidos;
- los usuarios ven respuestas duplicadas para una solicitud aceptada.
Estos síntomas, junto con sus marcas de tiempo, son suficientes para que el soporte diagnostique el problema.
## ¿A dónde vamos ahora?
- [Puerta de enlace y motor de giro](/es/v1.0/architecture/gateway-turn-engine)
- [Observabilidad](/es/v1.0/operations/observability)
- [Canales](/es/v1.0/webui/channels)