Notifications et livraison

Anyy peut publier des notifications immédiates et des messages visibles via le Gateway résident. La livraison tient compte du routage : l’assistant peut s’adresser à l’utilisateur actuel ou à l’origine fiable de la conversation de canal, sans viser des contacts externes arbitraires.

Deux actions de message

Action	Contenu et routage
Notification (notify_user)	Texte avec titre facultatif ; delivery peut choisir Gateway, une origine fiable ou une liaison par défaut sur un canal donné. Aucune entrée de pièce jointe.
Message (send_message)	Texte et pièces jointes compatibles ; target accepte uniquement current_user ou origin. Aucune entrée delivery ni sélection de canal.

Avec send_message, current_user utilise la route actuelle de l’environnement. Une demande Dashboard/TUI ordinaire utilise Gateway ; une conversation de canal fiable répond normalement à son origine. origin explicite exige des métadonnées de canal fiables et ne sélectionne pas la liaison par défaut d’une autre plateforme.

Les deux actions sont auditées. L’envoi n’est pas idempotent : réessayer peut produire un doublon.

Notifications dans l’historique

Les notifications système indépendantes associées à une conversation restent visibles après changement de conversation, retour ou actualisation. Elles conservent leur carte System notification au lieu de devenir une réponse d’agent. Les anciens avis se chargent avec l’historique et la reconnexion ne crée pas de deuxième copie.

Ces cartes sont des enregistrements d’affichage séparés des messages Pi. Elles n’entrent pas dans le contexte du modèle et ne changent pas la branche sélectionnée. Un message avec pièce jointe peut disposer de sa projection conversationnelle existante ; il n’est pas dupliqué en carte système indépendante.

Anyy attribue au corps protégé un propriétaire durable avant publication, distinct de la charge de nouvelle tentative de livraison. Effacer celle d’une livraison terminée n’efface pas cet historique. Supprimer la conversation supprime ses notifications avec elle.

Cela concerne les notifications enregistrées par l’implémentation actuelle. Un ancien avis dont le corps exact a déjà été libéré ne peut pas être reconstitué fiablement depuis l’état ou le résumé d’un travail. Les événements en direct de tout le profil sans association de session, dont Heartbeat, sont hors de cette garantie d’historique par conversation.

Destinations de livraison

Les travaux planifiés et notifications texte utilisent les destinations ci-dessous. none est disponible pour la gestion du planificateur dans Dashboard/CLI, mais n’est pas accepté par notify_user. Ces valeurs ne sont pas les cibles de send_message.

Destination	Signification
gateway	Publie dans le flux d’événements du Gateway résident
origin	Retourne à l’origine fiable de la conversation de canal actuelle
current_user_default	Résout la liaison par défaut de l’utilisateur ; notify_user exige un delivery.channel tel que telegram
none	Ne livre aucun résultat à l’utilisateur

Anyy ne considère pas les noms de plateforme comme des adresses arbitraires de destinataires. Une liaison de canal configurée et autorisée doit résoudre la route.

Demander un envoi à Anyy

Exemples :

When this check finishes, notify me with the title “Backup verified” and a one-line result.

Send this summary back to the current Channel conversation.

Pour une notification texte vers une liaison par défaut configurée :

Notify my default Telegram binding with a short text summary of this result.

Pour une pièce jointe, faites la demande dans la conversation Telegram fiable où le rapport est disponible :

Reply to this Telegram conversation with the generated report as an attachment.

La première demande peut utiliser notify_user avec delivery: { target: "current_user_default", channel: "telegram" }. Celle avec pièce jointe utilise send_message vers l’origine fiable. Les interfaces actuelles ne permettent pas à une demande Dashboard de joindre un rapport à une liaison Telegram par défaut arbitrairement choisie.

Sans origine fiable ni liaison par défaut, Anyy signale une route indisponible au lieu de deviner un destinataire.

Reçus et état de livraison

Une publication réussie prouve qu’Anyy a accepté et transmis l’événement dans sa chaîne de livraison. Elle ne prouve pas à elle seule la réception finale par Telegram, e-mail, SMS ou un autre service.

Les envois peuvent créer un reçu reflétant ensuite la progression de l’adaptateur. Les capacités varient : certains signalent un accusé, d’autres uniquement la transmission. Vérifiez la carte système de la conversation d’origine, l’enfant d’arrière-plan ou l’historique Cron, ainsi que la santé du canal ; fin d’exécution et livraison externe sont distinctes.

Éviter les nouvelles tentatives aveugles

Vérifiez le reçu ou la santé du canal avant de réessayer un envoi incertain. Un deuxième envoi peut créer un doublon si le premier est arrivé mais que son accusé a été retardé.

Pièces jointes

Une pièce send_message doit être disponible dans le périmètre de session actuel, et le canal actuel/d’origine fiable doit déclarer son type de média compatible. notify_user est uniquement textuel, même vers une liaison par défaut. Les pièces incompatibles sont rejetées sans être abandonnées silencieusement.

Configurer une route par défaut

Connectez le canal dans Dashboard → Channel ou avec anyy setup channel, vérifiez la règle d’accès/l’association et testez-le. Les travaux planifiés peuvent ensuite choisir current_user_default et un canal de livraison.

Consultez Plateformes de messagerie et Automatisations planifiées.

Dépannage

Problème	Solution
Aucune route par défaut	Configurez et vérifiez une liaison de canal pour l’utilisateur actuel
Livraison à l’origine indisponible	Lancez la demande depuis une conversation de canal fiable
Publication réussie sans message externe	Vérifiez reçu, état du Gateway et diagnostic du canal
Message en double	Arrêtez les tentatives automatiques et inspectez l’ancien reçu/événement
Pièce jointe rejetée	Utilisez un type de média compatible avec le canal sélectionné