Resumen

  • OpenAI abrió a las 00:55:27 UTC un incidente por tasas elevadas de errores con el código invalid_prompt.
  • La empresa aplicó una mitigación a la 01:39:33 y declaró la recuperación completa a las 02:20:19; el registro público cubre 1:24:52.
  • El registro del incidente no publica el estado HTTP; por separado, el SDK oficial convierte un HTTP 400 real en BadRequestError y no lo incluye entre los reintentos ordinarios.
  • Correlacionar el error local con el incidente oficial permite conservar operaciones posiblemente válidas sin asumir que todos los rechazos tuvieron origen en OpenAI.
  • No se publicaron causa raíz, tasa de fallos, geografía, modelos, puntos de acceso, volumen de solicitudes ni número de clientes afectados.

Las páginas de estado suelen mirarse después de que una alarma ya ha sonado. En esta incidencia, su papel podía ser anterior: cambiar la interpretación de la propia alarma. El mensaje invalid_prompt nombraba un problema de entrada, pero el proveedor estaba investigando y mitigando un evento de servicio con ese mismo síntoma.

La diferencia importa en sistemas automáticos. Un fallo atribuido al cliente puede terminar en una cola muerta sin aviso operativo. Uno atribuido al servidor puede activar guardia, retención y reintentos. Si el proveedor usa la primera etiqueta durante el segundo tipo de evento, la observabilidad local necesita una fuente de contraste.

La señal externa debe entrar con tiempo y alcance

El registro estructurado de OpenAI fija tres momentos. La investigación comenzó a las 00:55:27 UTC. La mitigación pasó a vigilancia a la 01:39:33. La resolución llegó a las 02:20:19. Esa secuencia permite crear una ventana de correlación precisa, no una regla indefinida.

Una aplicación puede marcar las respuestas invalid_prompt recibidas dentro de ese intervalo y compararlas con su línea base. Debe preguntar si aumentaron de forma brusca, si afectaron formas de solicitud que antes funcionaban y si el componente oficial coincide con la API utilizada.

El alcance no debe extenderse por comodidad. Un error idéntico anterior al inicio o muy posterior a la recuperación necesita su propio diagnóstico. Tampoco basta la coincidencia horaria para declarar que OpenAI causó cada rechazo: solicitudes verdaderamente inválidas pueden coexistir con la incidencia.

Un 400 sigue siendo evidencia útil

La documentación del cliente Python asigna el estado 400 a BadRequestError. En su conjunto automático de reintentos figuran problemas de conexión y los estados 408, 409, 429 y al menos 500. La implementación también puede obedecer una cabecera explícita x-should-retry, pero, por regla general, otro estado termina sin repetición. Esta es una regla condicional del cliente: OpenAI no ha dicho que las respuestas del incidente llevaran 400.

Ese diseño protege al servicio y al cliente de reenvíos inútiles. Una clave mal escrita o un parámetro imposible no mejoran con espera exponencial. La incidencia no convierte el 400 en una categoría desechable; demuestra que la categoría puede necesitar una segunda opinión temporal.

Por ello, la lógica local debería mantener dos campos: la clasificación recibida y la clasificación operativa. La primera conserva la respuesta exacta del proveedor. La segunda puede pasar de «error permanente» a «pendiente de corroboración» cuando el estado oficial y la telemetría coinciden.

La integración correcta no consulta la página a cada llamada

Incorporar el estado del proveedor no significa bloquear cada solicitud mientras se descarga una web. Un colector separado puede leer el feed oficial con una frecuencia razonable, registrar sus transiciones y publicar una señal interna con fecha de caducidad.

Las aplicaciones consumen esa señal junto con sus propios contadores. Si aparece una coincidencia, reducen la carga, conservan evidencia y ponen en cuarentena las operaciones repetibles. Si el feed no está disponible, la ausencia de información no debe interpretarse automáticamente como salud.

También conviene evitar que una etiqueta global silencie fallos locales. Una organización puede tener credenciales incorrectas, un despliegue defectuoso o una carga mal formada al mismo tiempo que existe un incidente público. La comparación debe sumar evidencia, no borrar diagnósticos.

Los identificadores permiten reconciliar, no solo alertar

El SDK oficial expone un identificador de solicitud en las excepciones APIStatusError fallidas. Guardarlo junto con la hora, el punto de acceso, el modelo, la versión del cliente y el número de intento permite investigar un caso concreto.

Una huella no reversible de la estructura de la solicitud ayuda a detectar que entradas equivalentes cambiaron de comportamiento. No hace falta —y puede ser peligroso— guardar el texto íntegro de una instrucción, datos personales o secretos para obtener esa comparación.

Después de la recuperación, esos registros permiten separar trabajos: los que realmente incumplían el contrato, los que parecen haber caído en la incidencia y los que ya produjeron un resultado. Solo el segundo grupo es candidato a un reintento limitado, y el tercero requiere verificar el efecto antes de repetir.

El rótulo “resuelto” no devuelve el trabajo descartado

OpenAI afirmó que todos los servicios afectados se habían recuperado. Su página identifica APIs como el componente afectado y advierte que la disponibilidad agregada puede diferir de la experiencia de cada cliente según nivel, modelo y función.

No hay un porcentaje público de error ni una cifra de organizaciones. Por tanto, 1:24:52 es la duración del registro oficial, no una medida uniforme de indisponibilidad para todo usuario. Tampoco prueba que una solicitud abandonada al principio haya reaparecido al final.

La página de estado aporta una frontera temporal y una declaración del proveedor. La telemetría del cliente aporta el inventario de trabajo. La operación termina solo cuando ambas se cruzan: se revisan los fallos, se preservan los realmente inválidos, se reenvían de forma acotada los que sean seguros y se confirma el resultado.

OpenAI todavía no ha explicado la causa, el estado HTTP ni por qué el fallo tomó ese nombre. Esa ausencia limita la atribución técnica: no permite presentar todos los errores homónimos ni las respuestas 400 del intervalo como parte del incidente. No elimina la lección. En una API crítica, el estado del proveedor no es solo un banner para humanos; puede ser una señal versionada que impide que una etiqueta equivocada decida por sí sola el destino de una operación.

Fuentes