Le comportement des messages iMessage dans OpenClaw

Deux choses arrivent à un iMessage avant que l’agent le voie : les lignes qu’Apple a séparées sont recollées, et les lignes arrivées pendant l’arrêt de la passerelle sont rejouées, mais seulement celles qui méritent de l’être. La seconde est là où la conception se voit, parce que la couche Push d’Apple peut vider des heures d’historique périmé dès qu’un pont se reconnecte. Voici la règle de fusion, le mécanisme de récupération, les deux fenêtres, et la ligne de journal à surveiller.

Fusionner les envois séparés

• Apple peut stocker une commande et son aperçu d’URL en lignes physiques séparées dans la base de discussions, et imsg 0.13.1 et suivants fusionnent ces lignes avant que la veille, l’historique ou la recherche renvoie le message, si bien qu’OpenClaw reçoit un seul message entrant logique sans ajouter de latence propre au canal.
• Aucun réglage de fusion n’est nécessaire : l’ancienne clé de fusion des messages privés du même expéditeur est retirée par la correction du doctor, et le débounce entrant générique reste disponible pour grouper volontairement des messages rapides sur un canal.
• Si un envoi commande plus URL arrive encore en deux tours d’agent, la solution est de mettre à jour imsg sur le Mac Messages par Homebrew.
• La récupération après un redémarrage du pont ou de la passerelle est toujours active, bâtie sur l’ingestion durable plus une barrière d’âge, et elle récupère à la fois les messages manqués pendant l’arrêt et supprime la bombe d’arriéré périmé qu’Apple peut vider après une récupération Push.

Faites tourner la passerelle sur le Mac Messages pour la fenêtre de récupération plus large.

Comment fonctionne la récupération

Avant d’avancer le curseur de récupération, OpenClaw journalise chaque ligne brute dans la file d’ingestion SQLite partagée avec son GUID Apple comme identifiant d’événement ; une ligne terminée laisse une pierre tombale pendant environ quatre heures, plafonnée à dix mille entrées, si bien qu’un rejeu du même GUID est écarté même après un redémarrage, et une ligne en attente reste récupérable jusqu’à ce que la distribution l’adopte. Au démarrage, le moniteur se souvient du dernier rowid de base admis durablement, un curseur persistant par compte, et le passe à l’abonnement de veille comme rowid de départ, si bien qu’imsg rejoue les lignes pas encore journalisées puis suit en direct, les lignes journalisées avant un plantage reprennent depuis SQLite, et le rejeu est borné aux cinq cents lignes les plus récentes et aux messages vieux d’environ deux heures au plus, les pierres tombales de GUID écartant tout ce qui a déjà été traité. Les lignes au-dessus de la limite de démarrage sont réellement en direct, et une ligne dont la date d’envoi est plus ancienne d’environ quinze minutes que son arrivée est l’arriéré de vidage Push et est supprimée, tandis que les lignes rejouées à la limite ou en dessous utilisent la fenêtre de récupération plus large, si bien qu’un message manqué récemment est livré et qu’un historique ancien ne l’est pas.

Fenêtres, signal, migration

• La récupération fonctionne avec les chemins de commande locaux et distants parce que le rejeu par rowid passe par la même connexion RPC d’imsg, et la différence est la fenêtre : quand la passerelle peut lire la base de discussions localement, elle ancre la limite de démarrage, plafonne l’étendue du rejeu et livre les messages manqués vieux de quelques heures, tandis que par un chemin SSH distant elle ne peut pas lire la base, si bien que le rejeu n’est pas plafonné et que chaque ligne utilise la barrière d’âge en direct, récupérant encore les manqués récents et supprimant l’arriéré ancien avec la fenêtre plus étroite ; faire tourner la passerelle sur le Mac Messages donne la fenêtre plus large.
• L’arriéré supprimé est journalisé au niveau par défaut plutôt qu’écarté en silence, avec le compte, l’heure d’envoi, un indicateur de récupération montrant quelle fenêtre s’est appliquée, et un décompte cumulé des lignes supprimées depuis le démarrage.
• Le bloc de rattrapage est déprécié parce que la récupération après arrêt est automatique : une configuration existante avec le rattrapage activé est honorée comme profil de compatibilité pour la fenêtre de rejeu, et les blocs de rattrapage désactivés ou non définis sont retirés et supprimés par la correction du doctor.

OpenClaw sur iMessage est le billet du canal auquel ce comportement appartient, et Configurer iMessage dans OpenClaw l’endroit où se configurent les chemins local et distant qui décident de la fenêtre.

Rejouer ce qui a été manqué, pas ce qui a été vidé

La barrière de quinze minutes est toute l’astuce : un message envoyé longtemps avant son arrivée n’est pas un message manqué, c’est Apple qui rattrape, et le traiter comme nouveau ferait répondre l’agent à la discussion de la semaine dernière. Le comportement des messages Telegram dans OpenClaw montre la file durable de Telegram que la même couche d’ingestion sert, et Dépanner iMessage dans OpenClaw ce qu’il faut vérifier quand plus rien n’arrive en entrée.

Sur Diali

iMessage ne fait pas partie des canaux que Diali connecte aujourd’hui : WhatsApp, Telegram, Discord, Slack, Mattermost, Matrix, SMS et voix. OpenClaw hébergé sur Diali est l’assistant et La sécurité chez Diali décrit la frontière qui s’applique à chaque canal connecté.

• Commande plus URL font un seul message une fois imsg à jour.
• Pierres tombales de GUID pendant quatre heures ; cinq cents lignes et deux heures de rejeu.
• Quinze minutes de plus que son arrivée signifie arriéré, pas message.