1 puntos por GN⁺ 1 일 전 | 1 comentarios | Compartir por WhatsApp
  • Se está produciendo una degradación del rendimiento de Pull Requests, y es posible que no se muestren todos los pull requests indexados en las páginas /pulls y /repo/pulls
  • Actualmente, el clúster de Elasticsearch no contiene todos los documentos indexados, pero los datos de los pull requests no se han perdido y se vuelven a indexar cuando se actualizan
  • Se están realizando en paralelo trabajos para reindexar los índices restantes y acelerar un full reindex para restaurar los resultados completos, priorizando la precisión y evitando impactos adicionales
  • En la tabla de estado de componentes, solo Pull Requests aparece en estado degradado; Git Operations, Webhooks, API Requests, Issues, Actions, Packages, Pages, Copilot, Codespaces y Copilot AI Model Providers figuran como Operational
  • En el historial reciente también se publican varios incidentes y medidas de recuperación, como degradación de búsqueda, fallas en jobs de Actions, fallas al iniciar sesiones del agente de Copilot, regresión en merge queue, demoras en Projects y fallas de conexión en Codespaces

Estado actual de la interrupción

  • Se está produciendo una degradación del rendimiento en Pull Requests, publicada como Incomplete pull request results in repositories
  • En las páginas /pulls y /repo/pulls, es posible que no se muestren todos los pull requests indexados
    • Actualmente, el clúster de Elasticsearch no contiene todos los documentos indexados
    • Los datos de los pull requests no se han perdido
    • Cuando un pull request se actualiza, se vuelve a indexar
    • También se está acelerando un full reindex para restaurar los resultados completos
  • Se están reindexando los índices restantes de Elasticsearch, priorizando la precisión y evitando impactos adicionales
    • Se mantiene un enfoque cuidadoso para hacer el backfill de datos de forma segura

Estado de los componentes

  • En la tabla de estado actual, solo Pull Requests aparece como Degraded Performance
  • El resto de los componentes principales están en estado Operational
    • Git Operations
    • Webhooks
    • API Requests
    • Issues
    • Actions
    • Packages
    • Pages
    • Copilot
    • Codespaces
    • Copilot AI Model Providers
  • También se muestra la disponibilidad de los últimos 90 días
    • Pull Requests 99.58% uptime
    • API Requests 99.95% uptime
    • Packages 99.97% uptime
    • Copilot AI Model Providers 100.0% uptime

Páginas de estado por región y vías de suscripción

Historial reciente de incidentes

  • 28 de abril: interrupción en algunos servicios de GitHub

    • Disruption with some GitHub services fue resuelto
    • En los jobs hosted Ubuntu de Actions se produjeron demoras al iniciar y fallas
      • Parte de las ejecuciones ubuntu-latest y ubuntu-24.04 se retrasaron o fallaron
      • En un momento dado, alrededor del 5% de los jobs se vieron afectados; luego bajó a menos del 2% y después a menos del 1%
    • Se mitigó el problema que impedía las ejecuciones de Actions y finalmente se restauró el funcionamiento normal
  • 27 de abril: degradación de GitHub Search

    • GitHub search is degraded fue resuelto
    • Problemas de conectividad con Elasticsearch y carga adicional provocaron fallas de búsqueda y problemas en varios subservicios
      • Se vieron afectados Issues, Pull Requests, Packages y Actions
      • Ocurrieron fallas en workflow runs, fallas al cargar projects y search timeout
    • Tras bloquear la causa de la carga adicional, comenzaron a verse señales de recuperación, y luego se pasó a monitoreo de estabilización
  • 27 de abril: incidente en sesiones de Codex de Copilot Cloud Agent

    • Disruption with some GitHub services fue resuelto
    • En Copilot Cloud Agent se produjeron fallas al iniciar sesiones del agente Codex
      • No se iniciaban desde ninguna vía de entrada, incluidas asignaciones de issues y menciones con comentarios @copilot
      • Se vio afectado el 0.5% de todos los trabajos de Copilot Cloud Agent, unas 2,000 ejecuciones fallidas
      • Otras sesiones de agente de Copilot no se vieron afectadas
    • La causa fue un model resolution mismatch en sesiones del agente Codex, que hacía que en runtime se seleccionara un modelo incompatible
    • Se desplegó una mitigación para que las sesiones del agente Codex eligieran un modelo predeterminado estable

Casos principales con divulgación de causa raíz

  • Regresión en merge queue de Pull Requests

    • Incident with Pull Requests fue resuelto
    • Al usar squash merge en merge queue, si había más de un PR en el merge group, se generaba un merge commit incorrecto
      • En merges posteriores, podían revertirse cambios de PR anteriores y cambios de commits previos
      • Durante el período afectado, 2,092 pull requests se vieron impactados
    • No se vieron afectados los PR fusionados fuera de merge queue ni algunos grupos que usaban merge o rebase
    • La causa fue que una nueva ruta de código para ajustar el cálculo de merge base se aplicó con un feature flag gating incompleto
    • Se revirtió el cambio de código y se forzó el despliegue en todo el entorno; además, se enviaron procedimientos de recuperación a los administradores de los repositorios afectados
    • Después de eso, se está ampliando el alcance de las pruebas de corrección de merge para incluir también grupos squash con múltiples PR
  • Imposibilidad de iniciar agentes Claude y Codex desde la web

    • Disruption with users unable to start Claude and Codex agent task from the web fue resuelto
    • No era posible iniciar una nueva agent task con Claude o Codex desde github.com
    • La causa fue un cambio en el código de enrutamiento de solicitudes de creación de tareas de Copilot mission control
    • Las agent tasks en curso y otras funciones de agente de Copilot no se vieron afectadas
    • Se restauró el servicio revirtiendo el cambio problemático, y se están agregando monitoreo adicional y pruebas de integración a la ruta de creación de tareas
  • Menciones @ de Copilot que no se procesaban

    • Disruption with some GitHub services fue resuelto
    • Las menciones @copilot en comentarios de pull requests no activaban la ejecución del agente de programación de Copilot
      • Aproximadamente 23,000 invocaciones, equivalentes al 0.5% de todos los comentarios en pull requests e issues, no fueron procesadas
      • La creación, consulta y respuesta de comentarios no se vieron afectadas
    • La causa fue un serialization error que impedía publicar eventos al downstream consumer
    • Tras desplegar una corrección para restaurar la publicación de eventos, el procesamiento volvió a la normalidad, y se está avanzando en revisar el esquema de eventos relacionado y mejorar el monitoreo
  • Interrupción de Copilot Chat y Cloud Agent

    • Disruption with Copilot chat and Copilot Coding Agent fue resuelto
    • Se produjeron errores en Copilot Chat y Copilot Cloud Agent de github.com, y durante ese tiempo no se pudieron usar
    • Copilot Memory, que estaba en vista previa, tampoco pudo usarse en sesiones de agente
    • La causa fue un problema de conexión a la base de datos generado por un cambio en la configuración de infraestructura
    • github.com se recuperó primero, y el resto de los despliegues regionales se fueron restaurando de forma gradual
  • Demoras en el servicio de Projects

    • Disruption with projects service fue resuelto
    • Era posible que Projects no se sincronizara o reflejara los cambios con demora
      • La demora en reflejar cambios llegó hasta aproximadamente 45 minutos
    • La causa fue que un serialization error provocó fallas de eventos y un aumento repentino de resync, sobrecargando la capa de procesamiento de eventos
    • Se mitigó aumentando la velocidad de procesamiento de los cambios entrantes y luego se recuperó consumiendo el backlog
  • Degradación en configuración predeterminada de code scanning y Code Quality

    • Partial degradation for code scanning default setup and for code quality fue resuelto
    • En nuevos pull requests no se activaban el code scanning default setup ni el análisis de code quality
    • También ocurría un problema por el que los issues recién creados no aparecían en el project board
    • La causa fue un serialization error que impedía activar correctamente el code scanning, el análisis de calidad de código y la actualización del project board
    • Se restauró la publicación de eventos de code scanning y code quality; en el lado del project board se recuperó con cambios de código adicionales y reindex
    • Los PR que no fueron procesados antes o durante el incidente requieren un nuevo push para que el análisis se vuelva a activar

Otros incidentes recientes

  • Disruption with some GitHub services
    • La experiencia web en GitHub.com se degradó y alrededor del 1.5% de las solicitudes web terminaron con error
    • En algunos momentos, cerca del 10% del tráfico web se volvió lento o falló
    • La causa fue la saturación de capacidad de un componente de caché en una región de centro de datos
    • Se restauró desviando el tráfico a regiones no afectadas y revirtiendo despliegues recientes
  • Incident with Codespaces
    • Falló la conexión a GitHub Codespaces mediante el editor VS Code
    • Aproximadamente el 40% de los jobs de inicio de codespace fallaron
    • La conexión por SSH no se vio afectada
    • La causa fue una interrupción en un upstream download service que bloqueó la descarga de VS Code Server necesaria al inicio
    • Se mitigó con una solución alternativa para usar una ruta de descarga secundaria cuando el endpoint principal está degradado
  • Disruption with some GitHub services
    • Al acceder a la página de Copilot Insights de GitHub Enterprise Cloud se producían errores 500
    • Aproximadamente 709 usuarios se vieron afectados, con un tiempo total de impacto de unas 5 horas y 10 minutos
    • La causa fue una falla de autenticación en el metrics pipeline y un cambio en las credenciales del tenant
    • Se está avanzando en herramientas de diagnóstico, monitoreo más granular y mejoras en alerting

1 comentarios

 
GN⁺ 1 일 전
Comentarios en Hacker News
  • Lo peor es que ahora también falla en silencio
    Por ejemplo, aunque haya decenas de PR, muestra "There aren’t any open pull requests.", lo que claramente lleva a la gente a una conclusión equivocada

    • La semana pasada, usando merge queue, también pasó que borró trunk por accidente, y eso igualmente falló en silencio
    • En nuestro caso, hasta bromeábamos con felicitarnos porque por fin parecía que habíamos terminado todos los PR
    • Incluso cuando sí aparece la lista de PR, a veces no muestra todos los PR de la categoría que estás viendo, lo cual es realmente perverso
  • Esto realmente me pega fuerte
    Hace unos meses, $PARENT_CONGLOMERATE obligó a toda su organización a migrar a GitHub por razones de sinergia y eficiencia, y ahora le toca a $DAYJOB dejar nuestro GitLab self-hosted
    Ya tengo varias quejas
    La política de IT sobre las cuentas de GH no tiene ni pies ni cabeza: no podemos usar ninguna cuenta existente, ya sea personal o una que alguien hubiera creado antes para $DAYJOB, y tenemos que crear otra cuenta nueva que cumpla con las reglas de IT
    Nosotros no usamos monorepo, así que aprovechábamos mucho los groups, pero GitHub no tiene un equivalente directo, así que hay que reorganizar manualmente los namespaces de los proyectos
    Y ahora encima la disponibilidad de GitHub está así
    Nuestro equipo tiene fechas de lanzamiento muy sensibles a ingresos, así que con uno o dos días de retraso ya podría definirse si cumplimos o no la meta mensual
    En otro contexto habríamos hecho un mirror por adelantado del código clave para ingresos, pero no parece valer la pena asumir el riesgo de armar una salida improvisada de ese tipo
    Ojalá pudiéramos culpar a The Synergy Mandate en el postmortem del futuro cercano, pero sé perfectamente que eso no va a pasar
    Solo espero que sigamos cumpliendo las metas de ingresos y que no recorten el producto por bajo desempeño
    Escribiendo esto me doy más cuenta de cuánto ha cambiado este trabajo desde que entré

  • Quiero volver a decírselo a todos los proyectos OSS
    Con una tarea simple de CI se puede sincronizar código entre varios forge de manera facilísima, y recibir notificaciones por correo de un segundo forge casi no agrega carga
    Como mínimo, deberían dejar abierta la opción de contribuir fuera de GitHub, y al final eso es mejor para todo el ecosistema

    • La sincronización de código en sí es fácil y trivial, y una tarea de CI en realidad solo resuelve esa parte
      En la mayoría de los proyectos, quizás ni siquiera eso sea absolutamente necesario
      Lo difícil es todo lo que rodea al código
      Los tickets y los PR, incluyendo el historial de los cerrados
      Los distintos enlaces que hacen referencia al proyecto
      La configuración de CI
      En proyectos grandes, la configuración de permisos de committers
      Y si hace falta, también hay que mover todas las reglas de push/commit/branch
      Todo eso es muy fastidioso de migrar en cada proyecto, y parte incluso podría perderse
      Pero el problema aún mayor es perder la plataforma principal para descubrir software
      Ojalá ya existiera un fediverse del software
    • Sincronizar es trivial, pero lo verdaderamente central es CI
      GitHub Actions sigue siendo la mejor opción, y ni la FSF ni otros laboratorios OSS han logrado ofrecer CI decente a los mantenedores de código abierto
      Además, la carga de CI también se ha disparado muchísimo comparada con antes
    • Montar tu propia instancia de GitLab también puede ser una buena solución
  • Ya siento que hay que empezar a empujar en serio las alternativas
    Esto ya está empezando a impactar de verdad a nuestro negocio, y no se ve ninguna señal de mejora

    • Si quieres una UI como la de GitHub, usa Forgejo o Gitea
      Toca aceptar la limitación de la estructura org/repo
      Si quieres una experiencia parecida pero un poco distinta, GitLab encaja mejor
      Si prefieres algo más cercano al estilo del kernel —hosting propio, estructura flexible de repositorios, autenticación de usuarios con ssh key y una web UI simple— entonces usa gitolite con cgit o gitweb
    • Llevamos años haciendo self-hosting de Gitea y Drone/Woodpecker, y funciona de maravilla
      Ya sea Gitea o Forgejo, alcanza perfectamente si lo que ofrecen te sirve
      A veces entro a estos hilos sobre caídas de GitHub para reírme un rato: nuestra instancia de Gitea ha tenido en total unos pocos minutos de downtime en los últimos años, y todo fue por upgrades planeados en la madrugada
    • Me sorprende que GitLab no reciba más atención
      No es una copia exacta, pero se acerca bastante; diría que la diferencia no es tanto como entre naranja y manzana, sino más bien como entre manzana y pera
    • Yo pensaba lo mismo
      Pero GitHub realmente es una plataforma pegajosa: cuando ya tienes actions y toda clase de integraciones montadas, cuesta mucho irse
      Aun así, que tenga caídas tan frecuentes ya está llegando a un nivel ridículo
    • Ahora mismo hacemos self-hosting de Git y CI con Forgejo, y estamos muy contentos con cómo funciona
  • No parece ser solo cosa de GitHub, sino una caída más amplia: https://downdetector.com

    • Lo más probable es que el denominador común sea Azure
  • Como hoy también es un día que termina en y, entonces eso significa que otra vez hay una caída de GitHub

  • Codeberg.org también está teniendo problemas ahora mismo

    https://status.codeberg.org/status/codeberg

    https://social.anoxinon.de/@codebergstatus/11647770704799298...

  • Si no te gusta que GitHub se caiga, y tampoco que la IA robe código, podrías probar sourcehut
    A mí me ha funcionado muy bien, y me gustaría que prosperara más como plataforma

    • Me gustó tanto la experiencia de explorar repos nuevos que me pasé por completo a Codeberg, y la mayoría de los proyectos que me interesan también están ahí
    • No entiendo qué tiene de distinto sourcehut
      Al final, ¿no es simplemente otro servicio centralizado?
  • Esta vez sí se está tardando demasiado
    Me hizo pensar en el chiste de que el equipo encargado de arreglarlo se topó con el límite de sesiones de Claude y no puede tocar nada hasta que termine el cooldown, y que la única persona que sabe arreglarlo sin IA salió para una cirugía
    También me pregunto qué va a pasar cuando se retire por completo la generación que sabía arreglar estas cosas sin IA

  • Cada vez que GitHub se cae, unas cuantas personas más se pasan a alternativas éticas, y la estructura en la que la comunidad FOSS tiene un SPOF en Microsoft se debilita un poco más

    https://sfconservancy.org/GiveUpGitHub/

    • Estoy de acuerdo con esa idea, pero el aspecto social de que tantos proyectos estuvieran reunidos en GitHub claramente tenía ventajas
      Era fácil colaborar, y ahora por varias razones la fricción está aumentando
      También está aumentando el uso de issues como spam, y están empezando a verse actividades aún más maliciosas
    • SPOF significa Single Point of Failure