¿Cómo funciona el manejo de errores en GraphQL?

Question

IT Interview Practice · Accepted Answer

GraphQL siempre devuelve HTTP **200** para un transporte correcto; los problemas se reportan en el cuerpo de la respuesta, no en el código de estado. Una respuesta tiene dos claves de nivel superior: **`data`** y **`errors`**, y ambas pueden estar presentes a la vez: eso es **datos parciales**.

## Datos parciales + el array errors

Si el resolver de un campo lanza una excepción, ese campo se vuelve `null`, se añade una entrada a `errors`, pero todos los demás campos siguen resolviéndose. El cliente obtiene lo que tuvo éxito más una descripción de lo que falló.

```json
{
  "data": { "user": { "name": "Ada", "posts": null } },
  "errors": [
    {
      "message": "Failed to load posts",
      "path": ["user", "posts"],        // exactamente qué campo falló
      "extensions": { "code": "DOWNSTREAM_TIMEOUT" }
    }
  ]
}
```

El campo **`extensions.code`** transporta un código de error legible por máquina para que los clientes puedan ramificar según él. Que un campo que lanza una excepción se anule solo a sí mismo o burbujee hacia arriba depende de la **nullability**: un campo non-null (`posts: [Post!]!`) que da error anula a su padre nullable más cercano en su lugar.

```js
import { GraphQLError } from "graphql";

Muchos equipos también modelan los errores **esperados** (validación, "email taken") como parte del schema mediante union/result types, reservando el array `errors` para los fallos **inesperados**, lo que mantiene limpio el tipado del happy path.

## Por qué es importante

Los entrevistadores indagan si sabes que los errores viven en el cuerpo junto con `data` parcial, que los códigos van en `extensions` y que la nullability controla cuánto burbujea un error. Confundir los errores de GraphQL con los códigos de estado HTTP es una señal clásica de quien solo ha usado REST.

Datos parciales + el array errors

Por qué es importante

Preguntas relacionadas