Hi everyone
I have the following request that contains 2 mutations, the first one goes through but the second one is supposed to fail because there is no Quotation with id: "5eb418c000de5aac00b1ccdc" in my Database
mutation {
a: updateQuotations(quotations: [
{
id: "5eb418c000de5aac00b1ccda"
name: "toto_from_update1"
}
])
{
quotations {
name
}
}
b: updateQuotations(quotations: [
{
id: "5eb418c000de5aac00b1ccdc"
name: "toto_from_update2"
}
])
{
quotations {
name
}
}
}
Only here is my result:
{
"data": null,
"errors": [
{
"message": "Object not found",
"locations": [
{
"line": 13,
"column": 3
}
],
"path": [
"b"
]
}
]
}
As you can see the error on b is correct but there is no data associated with a. Here is what I would expect it to be (fyi I am returning the object after its update):
{
"data": {
"a": {
"quotations": [
{
"name": "toto_from_update1"
}
]
},
}
"errors": [
{
"message": "Object not found",
"locations": [
{
"line": 13,
"column": 3
}
],
"path": [
"b"
]
}
]
}
It appears that this is the expected behaviour in GraphQL, so my question is: is this supported by Juniper, and if it is do you have any idea of what I might be doing wrong?
PS: If both of the mutations fail, I only get an error for the first one that failed. If both the mutations succeed I get the expected behaviour.
I can provide more information and code if needed.
@EituKo what is the return type of updateQuotations mutation? Is it Nullable or Non-Nullable?
@tyranron here is the updateQuotations mutation Rust function prototype:
pub fn update_quotations(
context: &Ctx,
quotations: Vec<quotation::UpdateQuotationArgs>,
) -> FieldResult<quotation::UpdateQuotationResponse>
pub struct UpdateQuotationResponse {
quotations: Vec<Quotation>,
}
I think it is Non-Nullable. From what I understand, Nullable fields are handled via Option<T> in Juniper, should my return type be FieldResult<Option<quotation::UpdateQuotationResponse>> ?
@EituKo yeah, you should try either that, or sending a batch of requests instead of a single multi-mutation request.
If an error is thrown while resolving a field, it should be treated as though the field returned null, and an error must be added to the "errors" list in the response.
If all fields from the root of the request to the source of the field error return Non-Null types, then the "data" entry in the response should be null.
@EituKo did that work?
@LegNeato yes it did
should my return type be FieldResult
This was the solution
Most helpful comment
@LegNeato yes it did
This was the solution