LangGraph 1.2.20 : un mode strict pour ne plus valider deux fois la même demande

Dans LangGraph, un agent peut se mettre en pause pour poser une question à un humain : « puis-je envoyer ce courriel ? », « quel montant dois-je rembourser ? ». La fonction s'appelle interrupt(), et l'application reprend l'exécution en renvoyant la réponse. La version 1.2.20, publiée le 5 novembre 2026, corrige un angle mort de ce mécanisme.

Le problème : une réponse périmée passait sans bruit

Jusqu'ici, si une application renvoyait une réponse visant une interruption qui n'était plus en attente, LangGraph l'ignorait sans rien signaler. Le graphe rejouait la tâche, se remettait en pause sur la même question, et le client n'avait aucun moyen de savoir que sa réponse n'avait servi à rien.

Le cas n'a rien de théorique. L'auteur de la modification cite deux situations courantes : deux onglets ouverts sur la même validation, ou une requête réseau relancée automatiquement. Chacune envoie une réponse qui était valable au moment où elle a été lue.

Ce que fait le mode strict

Le mode est facultatif. Une fois activé, le graphe principal vérifie la reprise avant d'écrire quoi que ce soit et lève une erreur UnknownInterruptError dans trois cas :

• la réponse vise un identifiant d'interruption qui n'est pas en attente (not_pending) ;
• la réponse est un dictionnaire vide (empty_map) ;
• une seule valeur est fournie alors que plusieurs interruptions attendent (ambiguous).

L'erreur indique les identifiants concernés et ceux qui sont réellement en attente, ce qui permet à l'interface d'afficher un message clair du type « cette demande a déjà été traitée ».

Un identifiant par question

Second changement, lié au premier : auparavant, toutes les questions posées par une même tâche partageaient un seul identifiant. Une réponse renvoyée deux fois à la première question pouvait donc être prise pour la réponse à la deuxième. Désormais, la première interruption conserve son identifiant d'origine et les suivantes en reçoivent un distinct.

Les identifiants enregistrés par des versions antérieures restent acceptés grâce à un mécanisme de repli. Autre effet : un nœud relancé après un échec réutilise la réponse déjà obtenue au lieu de reposer la question.

Les limites à connaître

• Dans la bibliothèque, l'activation passe par une clé de configuration privée (__pregel_strict_resume). Côté client, le SDK Python 0.4.14, publié le 6 novembre, ajoute un paramètre strict_resume aux méthodes runs.create, stream et wait.
• Sans cette activation, rien ne change : le comportement tolérant reste celui par défaut.
• La vérification ne s'applique pas aux graphes imbriqués, ni à la reprise depuis un point de sauvegarde que le fil a déjà dépassé.
• Un graphe distant (RemoteGraph) ne transmet pas la clé : c'est le côté distant qui décide.
• Plusieurs interruptions levées par une même tâche, par exemple des outils lancés en parallèle, reçoivent toujours leurs réponses dans l'ordre où la tâche les pose.
• Un relecteur a noté qu'une réponse sans identifiant, quand une seule interruption attend, suit toujours l'ancien chemin. Un autre correctif est en discussion sur ce point.

Une modification équivalente a été fusionnée dans la version JavaScript de LangGraph.

Notre lecture

Si vos agents déclenchent des actions réelles après validation humaine (envoi, paiement, écriture en base), ce mode mérite d'être activé. Une double validation silencieuse est exactement le genre de défaut qui ne se voit qu'en production. Mettez à jour LangGraph et le SDK, activez la reprise stricte sur un environnement de test, puis vérifiez que votre interface gère la nouvelle erreur. Si vous stockez des identifiants d'interruption de votre côté, contrôlez le cas des tâches qui posent plusieurs questions : ce sont les seules dont les identifiants changent.