Le ticket devient une pull request. Polylane creuse entre les deux.
Rejoindre la liste d'attenteIl vérifie d'abord ce qui a changé. La moitié des tickets remontent à un changement fait par quelqu'un.
SQS visibility timeout lowered on checkout-events
VisibilityTimeout on checkout-events dropped from 120s to 15s. Consumers that hold a message longer than 15 seconds will see it delivered twice; the dead-letter queue threshold is unchanged.
Les théories sont testées, pas crues. Confirmées uniquement avec des preuves venues de tes vrais systèmes.
Hyperdrive pool exhaustion after deploy 9f3c2a1
Confidence: strong · 3 of 3 passes
Upstream PlanetScale degradation
Confidence: definitive · 3 of 3 passes
Cold-start regression in the new isolate
Confidence: weak · 2 of 3 passes
Le correctif arrive prêt à relire. Cause racine, validation et diff inclus.
Cap retries on the checkout webhook worker #491
polylanemain from polylane/autofix/chat/k3x9f2-4e7d21a Retries on the checkout webhook worker were unbounded: a failing delivery re-queued itself forever and amplified load on payments-api. This caps delivery at 5 attempts with exponential backoff and dead-letters the payload after the last one.
What changed
worker/deliver.ts gains MAX_DELIVERY_ATTEMPTS = 5 and backoff between attempts; exhausted payloads land in checkout-webhooks-dlq instead of re-queueing.
Validation
npm test — 214 passed. A forced failing delivery stopped after 5 attempts and appeared in the dead-letter queue.
Comment Polylane fonctionne. Il apprend ton système, le surveille, enquête et agit.
-
Il apprend d'abord ton système
Le graphe de contexte cartographie chaque ressource et chaque dépendance à travers tes clouds, tes dépôts et tes fournisseurs d'observabilité. Les agents raisonnent sur une topologie réelle, pas sur des suppositions.
-
Détection sans seuils
Des vérifications intégrées pour chaque fournisseur, plus des vérifications générées à partir de tes propres requêtes enregistrées et de tes dashboards. Une passe statistique et un agent décident ensemble, et une amélioration ne lève jamais d'issue.
-
Des enquêtes qui montrent leurs preuves
Chaque affirmation renvoie à la requête, à la ligne de log ou à l'enregistrement de changement qui la fonde. Un verdict sans preuves retombe sur non concluant.
-
Les écritures se méritent, jamais présumées
Les comptes se connectent en lecture seule. Les rollbacks sont désactivés par défaut, limités en fréquence et consignés. Les changements de code passent par ta revue habituelle.
-
Il s'affûte chaque semaine
Mémoires, notes quotidiennes et requêtes de supervision reconfirmées contre des données réelles : l'enquête de juillet apprend de celle de juin.
Il se branche sur ce que tu fais déjà tourner. Connecte en lecture seule et commence.
Questions.
Comment confier un ticket à Polylane ?
Démarre un thread dans la console, via la CLI ou depuis ton éditeur via le serveur MCP, et décris le bug. Les agents prennent le relais avec tout le contexte de l'espace de travail : le graphe, la télémétrie, les enregistrements de changement et le code.
Et s'il ne trouve pas la cause ?
Il le dit. Les enquêtes se terminent résolues, diagnostiquées ou non concluantes : une enquête qui n'a pas pu atteindre les données ne confirme jamais, et tout ce qui exige une décision humaine devient une seule escalade, pas une boucle de relances.
Apprend-il des tickets passés ?
Oui. Les constats confirmés sont stockés comme mémoires et retrouvés par leur sens dans les threads suivants, et les notes quotidiennes tiennent un registre continu de ce qui s'est passé. L'enquête de juillet apprend de celle de juin.
Qui écrit le correctif ?
L'autofix de Polylane par défaut : enquête d'abord, écrit et validé, avec le raisonnement joint. Ou confie l'implémentation à Devin, Cursor ou Factory. Dans tous les cas, tu le relis.
Avec quels dépôts fonctionne-t-il ?
Les dépôts GitHub, connectés via l'app GitHub. Le correctif atterrit sur une branche du dépôt derrière le service affecté, avec l'enquête liée depuis le changement.