«Невозможно вернуть null для типа, не допускающего значения NULL: 'Person' в родительском 'Messages' (/ getMessages / sendBy)» в GraphQL SDL (aws appsync)
Я новичок в graphql. Я реализую приложение для реагирования с использованием aws appsync. Ниже приведен код, который я написал в схеме.
type Messages {
id: ID!
createdAt: String!
updateAt: String!
text: String!
sendBy: Person!
@relation(name: "UserMessages")}
type Person {
id: ID!
createdAt: String!
updateAt: String!
name: String!
messages: [Messages!]!
@relation(name: "UserMessages")}
Когда я пытался запросить значение sendBy, я получаю сообщение об ошибке
query getMessages{
getMessages(id : "a0546b5d-1faf-444c-b243-fab5e1f47d2d") {
id
text
sendBy {
name
}
}
}
{
"data": {
"getMessages": null
},
"errors": [
{
"path": [
"getMessages",
"sendBy"
],
"locations": null,
"message": "Cannot return null for non-nullable type: 'Person' within parent 'Messages' (/getMessages/sendBy)"
}
]
}
Я не понимаю эту ошибку, пожалуйста, помогите мне. Спасибо !! заранее
Ответы 5
Похоже, что путь [getMessages, sendBy] разрешается в значение null, а определение вашей схемы (sendBy: Person!) говорит, что поле sendBy не может разрешить значение null. Пожалуйста, проверьте, прикреплен ли преобразователь к полю sendBy в типе Messages.
Если подключен преобразователь, включите журналы CloudWatch для этого API (это можно сделать на странице настроек в консоли, выберите вариант ВСЕ). Вы должны иметь возможность проверить, какое сопоставление запросов и ответов было разрешено для пути [getMessages, 0, sendBy].
Привет, Бхарат, можете ли вы включить журналы CloudWatch с настройкой ALL и публиковать контент (если в нем нет конфиденциальных данных)? Я могу помочь вам с этой информацией. Спасибо.
Спасибо за этот шанкар, но есть ли у нас какие-либо другие альтернативы для решения этой проблемы. Я думаю, что нам нужно что-то закодировать после прикрепления sendBy к сообщению типа в шаблоне сопоставления. Я не уверен в информации. Можете ли вы мне помочь?
У меня не так много информации, чтобы помочь вам в этом. Было бы полезно получить информацию из журналов CloudWatch, чтобы узнать, что пошло не так. Как выглядят ваши шаблоны сопоставления запросов и ответов? Какие данные возвращаются по пути ["getMessages", "sendBy"]? Какой у вас источник данных для резолвера, подключенного к sendBy? Пожалуйста, обратитесь к следующей документации о том, как настроить резолверы: docs.aws.amazon.com/appsync/latest/devguide/…
Я столкнулся с аналогичной проблемой, когда работал над настройкой CloudFormation. В моей конкретной ситуации я неправильно настроил проекцию для глобальных вторичных индексов. Поскольку атрибуты не были спроецированы в индекс, я получал идентификатор в ответе, но нулевое значение для всех остальных значений. Обновление ProjectionType до "ALL" решило мою проблему. Не сказать, что это «правильный» параметр, но для моей конкретной реализации это было необходимо.
Подробнее о прогнозе глобального вторичного индекса для CloudFormation можно найти здесь: https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-dynamodb-projectionobject.html
Attributes that are copied (projected) from the source table into the index. These attributes are additions to the primary key attributes and index key attributes, which are automatically projected.
У меня была аналогичная проблема.
Со мной произошла проблема с решателем обновлений. Я обновлял поле, которое использовалось как GSI (глобальный вторичный индекс). Но я не обновлял GSI, поэтому при запросе GSI индекс существует, но ключ для этого атрибута изменился.
Если вы используете Dynamo DB, вы можете начать отладку там. Вы можете проверить элемент и посмотреть, есть ли у вас ссылка на первичный ключ или индексы.
Это может показаться глупым, но все же разработчики допускают такие ошибки, и я тоже. В подписке клиент может получать только те поля, которые выводятся в запросе на мутацию. Например, если ваш запрос на мутацию выглядит так:
mutation newMessage {
addMessage(input:{
field_1: "",
field_2: "",
field_n: "",
}){
field_1,
field_2
}
}
В приведенной выше мутации, поскольку мы выводим только field_1 и field_2. Клиент может получить единственное подмножество этих полей.
Поэтому, если в схеме для подписки вы определили field_3 как обязательное (!), И поскольку вы не выводите field_3 в приведенной выше мутации, это вызовет ошибку с сообщением Cannot return null для типа, не допускающего значения NULL: field_3.
У меня была аналогичная проблема.
для меня проблема заключалась в возвращаемом типе схемы. Когда я делал запрос с PK в таблице Dynamodb ... он возвращал список элементов или данных, которые вы можете сказать. но в моей схеме я определил схему как единый формат структуры.
Ошибка была устранена, когда я просто сделал возвращаемый тип в схеме как список элементов.
нравиться
type mySchema {
[ID]
}
вместо введите mySchema
{
id : ID!
name : String!
details : String!
}
Эта ошибка возникает по нескольким причинам. так что ваша причина может быть в другом, но я только что опубликовал один из сценариев.
Привет, привет, спасибо за ваше время, я пробовал, но все еще получаю ту же ошибку и мог бы быть более конкретным, как проверить каково было сопоставление разрешенного запроса / ответа для пути [getMessages, 0, sendBy].