Hi,
We have found the issue with updating one specific customer in a Shopify store. Here is our GraphQL:
Summary
mutation UpdateCustomer($input: CustomerInput!) {
customerUpdate(input: $input) {
customer {
id
email
firstName
lastName
displayName
createdAt
avatar: metafield(namespace: “mega-community”, key: “avatar”) {
reference {
… on MediaImage {
image {
url
}
}
}
}
bio: metafield(namespace: “mega-community”, key: “bio”) {
value
}
nickname: metafield(namespace: “mega-community”, key: “nickname”) {
value
}
useNickname: metafield(namespace: “mega-community”, key: “useNickname”) {
value
}
}
userErrors {
field
message
}
}
}
{
“input”: {
“metafields”: [
{
“namespace”: “mega-community”,
“key”: “bio”,
“value”: “PANACHE Founder / Leadout”,
“type”: “multi_line_text_field”
},
{
“namespace”: “mega-community”,
“key”: “avatar”,
“value”: “gid://shopify/MediaImage/40103266091247”,
“type”: “file_reference”
}
],
“id”: “gid://shopify/Customer/252951855129”
}
}
{
“data”: {
“customerUpdate”: {
“customer”: {
“id”: “gid://shopify/Customer/252951855129”,
“email”: “REDACTED_FOR_PRIVACY”,
“firstName”: “REDACTED_FOR_PRIVACY”,
“lastName”: “REDACTED_FOR_PRIVACY”,
“displayName”: “REDACTED_FOR_PRIVACY”,
“createdAt”: “2017-12-23T16:36:36Z”,
“avatar”: null,
“bio”: null,
“nickname”: null,
“useNickname”: null
},
“userErrors”:
}
},
“extensions”: {
“cost”: {
“requestedQueryCost”: 16,
“actualQueryCost”: 14,
“throttleStatus”: {
“maximumAvailable”: 4000,
“currentlyAvailable”: 3986,
“restoreRate”: 200
}
}
}
}
x-request-id: 3f6d106c-6846-45d5-a95d-6d1456426f49-1786435297
Unfortunately, when request fails, there is no hint in a response, why this failes for one specific customer, but works for all other customers we tested with.
Can anyone from Shopify team help us in investigating this?
Hi @architechpro! I looked into the request ID you shared. On our side the request completed successfully with no errors surfaced, which lines up with the empty userErrors in your response. The fact the metafield values return null make it an unusual combination, so I need a few more data points to pin down where the disconnect is.
- Run a standalone query for the two metafields on this customer and share the full response plus its
x-request-id:
query {
customer(id: "gid://shopify/Customer/252951855129") {
bio: metafield(namespace: "mega-community", key: "bio") { value }
avatar: metafield(namespace: "mega-community", key: "avatar") {
reference { ... on MediaImage { image { url } } }
}
}
}
This tells us whether the values exist in the stored data but aren’t being returned by the mutation, or whether they never persisted at all.
-
Run the same customerUpdate against a different customer on the same store, using the same app and API version, and share that response and x-request-id too. A successful run on another customer lets us contrast the two transaction paths.
-
If convenient, try a partial update with only mega-community.bio on the affected customer, excluding the file_reference input. That isolates whether the avatar reference is causing the entire metafield update to be dropped.
Once I have those, I can narrow this down further and raise it with the relevant team internally if need be - thanks for reporting this here!
Hey @architechpro! Thanks for running those extra checks and for waiting to hear back from me - I confirmed that the submitted metafields aren’t persisting for this customer, including in the bio-only test, while the same request shape succeeds for the control customer. That rules out the avatar file_reference as the sole trigger.
I’ve raised this customer-specific persistence behavior with the relevant team. I don’t have a confirmed cause or workaround yet, but I’ll update this thread once we have a concrete finding.
@architechpro Thanks for waiting to hear back! I raised this internally with the teams responsible for metafields and customer updates, and they confirmed what is happening. This customer has an unrelated metafield, custom.do_you_have_a_design_or_do_you_need_design_services, whose saved value no longer matches its current definition. It is separate from the mega-community fields in your request, so your app might not have visibility into it.
The customerUpdate mutation validates all the customer’s existing metafields during the save. That unrelated invalid value causes the save to roll back, including the new metafields. Because it was not part of your input, its validation error is omitted, which results in HTTP 200, userErrors: [], and null metafield values.
To work around this, either you or the merchant will need to update that existing metafield to a value allowed by its current definition, or remove it, then retry customerUpdate.
The customers team agree that this is a confusing situation and have opened an internal tracking issue to work on making it better. I cannot confirm an ETA or even that this behavior will change, but I can assure you it’s being assessed by the right people.
If the retry still fails after correcting or removing the invalid metafield, share the new x-request-id and response so we can compare it with the original behavior. Thanks a lot for raising this here!