AiHummer est conçu pour terminer une réponse même lorsqu’une connexion de canal tombe brièvement ou que l’instance redémarre. Cette page décrit le comportement visible et les actions qu’un administrateur devrait entreprendre. Il ne nécessite intentionnellement pas que vous compreniez la machinerie interne de livraison de la plateforme.
Ce que les utilisateurs devraient voir
Après qu’un utilisateur envoie un message :
La session affiche le message qui a été accepté.
L’agent le traite et produit une réponse visible.
Si le canal est temporairement indisponible, la livraison est réessayée.
Lorsque le canal revient, la réponse apparaît sans que l’utilisateur ait à envoyer
la même demande à nouveau.
La même demande ne devrait pas produire de réponses visibles en double. Si un client se reconnecte, il peut recharger l’historique récent, mais la conversation elle-même reste une session continue.
Que se passe-t-il après un redémarrage
Une mise à jour d’instance, un redémarrage de l’hôte ou un redémarrage inattendu ne devrait pas faire disparaître une requête acceptée. Le travail qui peut se poursuivre en toute sécurité reprend après que l’instance redevient saine. L’utilisateur devrait voir soit la réponse complète, soit un état d’échec clair qui peut être réessayé.
[!NOTE]
Ne répétez pas immédiatement une demande pendant que l’instance se rétablit encore.
Attendez d’abord que l’état de santé redevienne normal et actualisez la session.
Cela évite de créer une demande réellement nouvelle parallèlement à celle en cours de récupération.
Si une réponse n’arrive pas
Ouvrir Statut et confirmer que l’instance et le canal affecté sont
sain.
Ouvrez la session et actualisez-la une fois.
Vérifier Notifications pour un avertissement de livraison ou de chaîne.
Envoyez un nouveau message de test court seulement après que la demande précédente soit visible
résultat de succès ou d’échec.
Si le problème se répète, enregistrez l’heure, la session, le canal et l’erreur visible,
puis contactez le support. Ne collez jamais de clés API ou de secrets de canal dans un ticket.
Pour la récupération spécifique à un canal, ouvrez le guide correspondant sous Chaînes. Par exemple, les contrôles de santé, voir Systemd et contrôles de santé.
Ce que les administrateurs doivent surveiller
Observez les résultats visibles par l’utilisateur plutôt que les détails de mise en œuvre :
les réponses cessent d’atteindre un canal tandis que les autres canaux fonctionnent ;
les sessions restent en cours anormalement longtemps;
l’instance passe de manière répétée entre saine et indisponible ;
les notifications signalent des échecs de livraison répétés ;
les utilisateurs voient des réponses en double pour une demande acceptée.
Ces symptômes, ainsi que leurs horodatages, sont suffisants pour que le support puisse diagnostiquer le problème.
AiHummer est conçu pour terminer une réponse même lorsqu'une connexion de canal tombe brièvement ou que l'instance redémarre. Cette page décrit le **comportement visible** et les actions qu'un administrateur devrait entreprendre. Il ne nécessite intentionnellement pas que vous compreniez la machinerie interne de livraison de la plateforme.
## Ce que les utilisateurs devraient voir
Après qu'un utilisateur envoie un message :
1. La session affiche le message qui a été accepté.
2. L'agent le traite et produit une réponse visible.
3. Si le canal est temporairement indisponible, la livraison est réessayée.
4. Lorsque le canal revient, la réponse apparaît sans que l'utilisateur ait à envoyer
la même demande à nouveau.
La même demande ne devrait pas produire de réponses visibles en double. Si un client se reconnecte, il peut recharger l'historique récent, mais la conversation elle-même reste une session continue.
## Que se passe-t-il après un redémarrage
Une mise à jour d'instance, un redémarrage de l'hôte ou un redémarrage inattendu ne devrait pas faire disparaître une requête acceptée. Le travail qui peut se poursuivre en toute sécurité reprend après que l'instance redevient saine. L'utilisateur devrait voir soit la réponse complète, soit un état d'échec clair qui peut être réessayé.
> [!NOTE]
> Ne répétez pas immédiatement une demande pendant que l'instance se rétablit encore.
> Attendez d'abord que l'état de santé redevienne normal et actualisez la session.
> Cela évite de créer une demande réellement nouvelle parallèlement à celle en cours de récupération.
## Si une réponse n'arrive pas
1. Ouvrir **Statut** et confirmer que l'instance et le canal affecté sont
sain.
2. Ouvrez la session et actualisez-la une fois.
3. Vérifier **Notifications** pour un avertissement de livraison ou de chaîne.
4. Envoyez un nouveau message de test court seulement après que la demande précédente soit visible
résultat de succès ou d'échec.
5. Si le problème se répète, enregistrez l'heure, la session, le canal et l'erreur visible,
puis contactez le support. Ne collez jamais de clés API ou de secrets de canal dans un ticket.
Pour la récupération spécifique à un canal, ouvrez le guide correspondant sous [Chaînes](/fr/v1.0/webui/channels). Par exemple, les contrôles de santé, voir [Systemd et contrôles de santé](/fr/v1.0/operations/systemd-health).
## Ce que les administrateurs doivent surveiller
Observez les résultats visibles par l'utilisateur plutôt que les détails de mise en œuvre :
- les réponses cessent d'atteindre un canal tandis que les autres canaux fonctionnent ;
- les sessions restent en cours anormalement longtemps;
- l'instance passe de manière répétée entre saine et indisponible ;
- les notifications signalent des échecs de livraison répétés ;
- les utilisateurs voient des réponses en double pour une demande acceptée.
Ces symptômes, ainsi que leurs horodatages, sont suffisants pour que le support puisse diagnostiquer le problème.
## Où aller ensuite
- [Passerelle et moteur de virage](/fr/v1.0/architecture/gateway-turn-engine)
- [Observabilité](/fr/v1.0/operations/observability)
- [Chaînes](/fr/v1.0/webui/channels)
