El ticket se convierte en un pull request. Polylane hace la excavación de por medio.
Únete a la lista de esperaPrimero comprueba qué cambió. La mitad de los tickets se remontan a un cambio que alguien hizo.
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.
SetQueueAttributes CloudTrail · deploy-bot · 12:41:02Z attached to this record's delta window Las teorías se prueban, no se dan por buenas. Confirmadas solo con evidencia de tus sistemas reales.
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
El arreglo llega listo para revisar. Causa raíz, validación y diff incluidos.
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.
Cómo funciona Polylane. Aprende tu sistema, lo vigila, investiga y actúa.
-
Primero aprende tu sistema
El grafo de contexto mapea cada recurso y dependencia entre tus nubes, repositorios y proveedores de observabilidad. Los agentes razonan sobre topología real, no sobre suposiciones.
-
Detección sin umbrales
Comprobaciones integradas para cada proveedor, más comprobaciones generadas a partir de tus propias consultas guardadas y paneles. Una pasada estadística y un agente deciden juntos, y una mejora nunca abre un issue.
-
Investigaciones que muestran pruebas
Cada afirmación enlaza con la consulta, la línea de log o el registro de cambio que la respalda. Un veredicto sin evidencia pasa a no concluyente.
-
Las escrituras se ganan, nunca se presuponen
Las cuentas se conectan en solo lectura. Los rollbacks están desactivados por defecto, con límite de frecuencia y registrados. Los cambios de código pasan por tu revisión habitual.
-
Cada semana afina más
Memorias, notas diarias y consultas de monitorización reconfirmadas contra datos reales: la investigación de julio aprende de la de junio.
Se conecta a lo que ya ejecutas. Conecta en solo lectura y empieza.
Preguntas.
¿Cómo le paso un ticket a Polylane?
Inicia un hilo en la consola, desde la CLI o desde tu editor a través del servidor MCP, y describe el bug. Los agentes se encargan desde ahí con todo el contexto del espacio de trabajo: el grafo, la telemetría, los registros de cambio y el código.
¿Y si no puede encontrar la causa?
Lo dice. Las investigaciones terminan resueltas, diagnosticadas o no concluyentes: una investigación que no pudo llegar a los datos nunca confirma, y cualquier cosa que necesite una decisión humana se convierte en un solo escalado, no en un bucle insistente.
¿Aprende de tickets anteriores?
Sí. Los hallazgos confirmados se guardan como memorias y se recuperan por significado en hilos posteriores, y las notas diarias mantienen un registro continuo de lo que pasó. La investigación de julio aprende de la de junio.
¿Quién escribe el arreglo?
El autofix de Polylane por defecto: investigado primero, escrito y validado, con el razonamiento adjunto. O entrega la implementación a Devin, Cursor o Factory. En cualquier caso, tú lo revisas.
¿Con qué repositorios funciona?
Repositorios de GitHub, conectados mediante la app de GitHub. El arreglo aterriza en una rama del repositorio detrás del servicio afectado, con la investigación enlazada desde el cambio.