Contexte et problème

Critic, l’outil de revue de code assisté par IA, devait gérer les questions posées aux agents lorsqu’un développeur travaillait hors ligne. Initialement, chaque appareil pouvait placer une question dans une file d’attente best‑effort sans garantie d’exclusivité. En cas de perte de connexion, la session restait sur l’appareil d’origine, mais aucune logique ne prévenait la duplication ou la perte de la conversation, ce qui pouvait bloquer le flux de travail.

Mise en œuvre du bail

Le nouveau mécanisme introduit un lease token qui attribue la propriété d’une question à un seul appareil à la fois. Le texte de la mise à jour précise que « exactly one connected device owns a question at a time », et que le bail expire après 45 secondes si l’appareil ne renouvelle pas son droit. Cette durée limite la fenêtre pendant laquelle un appareil déconnecté conserve la main, tout en libérant rapidement la question pour d’autres appareils. Le code modifié dans agentQuestions.ts transforme la file d’attente en une hand‑off atomique :

// Pseudo‑code extrait du diff
function claimQuestion(questionId) {
  const lease = generateLeaseToken();
  if (queue.claimAtomically(questionId, lease)) {
    startTimer(45_000, () => releaseLease(questionId, lease));
    return lease;
  }
  return null;
}

Le token est stocké dans la même structure que la file, évitant ainsi une table de battement (heartbeat table) supplémentaire. Le développeur Shreyash justifie ce choix en soulignant que le heartbeat aurait nécessité une visibilité supplémentaire sur quel appareil répond, alors que le bail suffit à garantir l’exclusivité.

Impact sur la fiabilité du flux de travail

Grâce au bail, les questions posées depuis la page de changement attendent désormais l’agent de codage du développeur, même si son appareil est hors ligne. Le texte indique que « a lost device returns its work after 45 seconds without losing the thread », ce qui signifie que la conversation reprend automatiquement dès que le bail est libéré. Le composant agent-question-status.tsx a été enrichi pour afficher l’appareil en cours de réponse et pour convertir un bail expiré en état Reconnecting, offrant ainsi un retour visuel immédiat sans requête supplémentaire.

Cette approche réduit le risque de boucles infinies, comme le souligne Hafedh : « Is there a cap on `attempts`? A question that crashes every device would loop forever ». En limitant la durée du bail, le système empêche qu’une même question soit ré‑enfilée indéfiniment, car chaque expiration rend la question à nouveau disponible pour un autre appareil.

Limites et perspectives

Le mécanisme repose sur la synchronisation temporelle des appareils ; des horloges désynchronisées pourraient entraîner des expirations prématurées ou des conflits de revendication. De plus, le texte ne mentionne pas de stratégie de récupération en cas de perte du token pendant la période de 45 secondes, ce qui pourrait laisser la question dans un état indéfini si l’appareil ne parvient pas à libérer le bail correctement. Enfin, l’absence d’un tableau de heartbeat signifie que l’interface ne peut pas afficher en temps réel quels appareils sont actifs, ce qui pourrait être utile pour le diagnostic en environnement multi‑développeur.

Dans l’ensemble, le passage d’une file d’attente best‑effort à un système de bail atomique renforce la cohérence du dialogue agent‑développeur, minimise les blocages liés aux déconnexions et simplifie l’infrastructure en évitant des tables de suivi supplémentaires.