GraphQL всегда возвращает HTTP 200 при успешном транспорте; проблемы сообщаются в теле ответа, а не в коде статуса. У ответа есть два ключа верхнего уровня: data и errors, и оба могут присутствовать одновременно — это частичные данные (partial data).
Если resolver одного поля бросает исключение, это поле становится , в добавляется запись, но все остальные поля всё равно разрешаются. Клиент получает то, что удалось, плюс описание того, что не удалось.
nullerrors{
"data": { "user": { "name": "Ada", "posts": null } },
"errors": [
{
"message": "Failed to load posts",
"path": ["user", "posts"], // какое именно поле не удалось
"extensions": { "code": "DOWNSTREAM_TIMEOUT" }
}
]
}
Поле extensions.code несёт машиночитаемый код ошибки, чтобы клиенты могли ветвиться по нему. Обнулит ли брошенное поле только себя или пузырёк поднимется выше, зависит от nullability: non-null поле (posts: [Post!]!), в котором произошла ошибка, обнуляет ближайшего nullable-родителя.
import { GraphQLError } from "graphql";
const resolvers = {
Mutation: {
transfer: (_p, args, ctx) => {
if (!ctx.user) {
// прикрепляем стабильный код, по которому клиенты могут ветвиться; скрываем внутренние детали
throw new GraphQLError("Not authenticated", {
extensions: { code: "UNAUTHENTICATED" },
});
}
// ...
},
},
};
Многие команды также моделируют ожидаемые ошибки (валидация, «email занят») как часть схемы через union/result-типы, оставляя массив errors для неожиданных сбоев — тем самым сохраняя чистую типизацию happy-path.
Интервьюеры выясняют, знаете ли вы, что ошибки живут в теле вместе с частичными data, что коды принадлежат extensions, и что nullability управляет тем, насколько высоко поднимается ошибка. Путаница ошибок GraphQL с HTTP-статусами — классический признак того, что человек использовал только REST.
Библиотека вопросов для IT-собеседований с подробными ответами — от Junior до Senior.
Поддержать