Dashboard

Le ticket devient une pull request. Polylane creuse entre les deux.

Rejoindre la liste d'attente

Il vérifie d'abord ce qui a changé. La moitié des tickets remontent à un changement fait par quelqu'un.

Clouds prod-aws Changes

SQS visibility timeout lowered on checkout-events

Moderate impact configuration ·Synced 12 minutes ago

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.

What we're watching
ApproximateAgeOfOldestMessage
checkout-events · baseline at change 3.2s · worse if up
Watching: no issue since this change
NumberOfMessagesReceived
checkout-events · baseline at change 41/min · worse if up
Watching: no issue since this change
Triggering events
SetQueueAttributes CloudTrail · deploy-bot · 12:41:02Z attached to this record's delta window
Full diff (3 changes)
Nodes (2) Edges (1)
2 nodes modified · 1 edge removed

Les théories sont testées, pas crues. Confirmées uniquement avec des preuves venues de tes vrais systèmes.

H1 Confirmed

Hyperdrive pool exhaustion after deploy 9f3c2a1

Confidence: strong · 3 of 3 passes

Prosecution confirmed
Defense confirmed
Neutral confirmed
H2 Refuted

Upstream PlanetScale degradation

Confidence: definitive · 3 of 3 passes

Prosecution refuted
Defense refuted
Neutral refuted
H3 Inconclusive

Cold-start regression in the new isolate

Confidence: weak · 2 of 3 passes

Prosecution inconclusive
Defense refuted
Neutral inconclusive

Le correctif arrive prêt à relire. Cause racine, validation et diff inclus.

github.com/coreplane/payments-api/pull/491

Cap retries on the checkout webhook worker #491

polylane
Open polylane wants to merge 1 commit into main from polylane/autofix/chat/k3x9f2-4e7d21a
Conversation 1 Commits 1 Checks 1 Files changed 2
polylane bot commented 6 minutes ago ···

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.

Root cause · Why it's safe · Out of scope
polylane added commit 4e7d21a Verified
Review required At least 1 approving review is required
ci / test Successful in 3m 12s Details
Review required Waiting on your review: Polylane never merges on its own
Merging is blocked

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.

Plus de cas d'usage

Des tickets en entrée. Des pull requests en sortie. Le backlog avance enfin tout seul.