GraphQL metafieldsSet Mutation Returns Incorrect Data

Hello everyone,

I’ve been running into a strange issue with the metafieldsSet mutation, and I wanted to see if anyone else has encountered this or knows a reliable workaround.

Problem Summary:

When I use the metafieldsSet mutation to create multiple metafields with similar keys (including trailing spaces), the response I get indicates that all metafields have been created successfully, with each having its own unique value and the same id. However, when I query the metafields afterwards, I get a different set of metafields, with a different id, and the key-value pairs do not match the initial response from metafieldsSet.

Api version: 2024-10

Mutation Request Example:

mutation metafieldsSet($metafields: [MetafieldsSetInput!]!) {
  metafieldsSet(metafields: $metafields) {
    metafields {
      id
      key
      namespace
      value
    }
  }
}

Variables:

{
  "metafields": [
    {
      "ownerId": "gid://shopify/Page/82760171623",
      "key": "test",
      "type": "single_line_text_field",
      "namespace": "the_same",
      "value": "without spaces"
    },
    {
      "ownerId": "gid://shopify/Page/82760171623",
      "key": "test ",
      "type": "single_line_text_field",
      "namespace": "the_same",
      "value": "WITH single space"
    },
    {
      "ownerId": "gid://shopify/Page/82760171623",
      "key": " test ",
      "type": "single_line_text_field",
      "namespace": "the_same",
      "value": "WITH two spaces"
    }
  ]
}

Response:

    "metafieldsSet": {
      "metafields": [
        {
          "id": "gid://shopify/Metafield/28307977502823",
          "key": "test",
          "namespace": "the_same",
          "value": "without spaces"
        },
        {
          "id": "gid://shopify/Metafield/28307977502823",
          "key": "test ",
          "namespace": "the_same",
          "value": "WITH single space"
        },
        {
          "id": "gid://shopify/Metafield/28307977502823",
          "key": " test ",
          "namespace": "the_same",
          "value": "WITH two spaces"
        }
      ],
      "userErrors": []
    }
  }

The response from Shopify indicates that all three metafields were successfully created, and they all have the same ID (28307977502823), but with different keys and values.

Verification:

When I subsequently run a query to verify what metafields are present, the results do not match what I expected:

query selectMetafield {
  page(id: "gid://shopify/Page/82760171623") {
    metafields(first: 10) {
      nodes {
        key
        namespace
        value
        id
      }
    }
  }
}

Response:

{
  "page": {
    "metafields": {
      "nodes": [
        {
          "key": "test",
          "namespace": "the_same",
          "value": "WITH single space",
          "id": "gid://shopify/Metafield/28307977470055"
        },
        {
          "key": " test ",
          "namespace": "the_same",
          "value": "WITH two spaces",
          "id": "gid://shopify/Metafield/28307977502823"
        }
      ]
    }
  }
}

It turns out that:

  • There are only two metafields.
  • The first metafield has a key of “test” and value “WITH single space”, but a new id (28307977470055), which was not returned during the initial mutation.
  • The third metafield seems correct, with key " test " and value “WITH two spaces”.

The issue here is that I can’t trust the response from the initial metafieldsSet mutation, as the actual keys, values, and IDs of the created metafields are different when verified afterwards.

Deletion Issues:

Additionally, when I tried to delete the metafields using the metafieldsDelete mutation (since metafieldDelete is deprecated), I encountered an unexpected error.

Mutation:

mutation metafieldsDelete($metafields: [MetafieldIdentifierInput!]!) {
  metafieldsDelete(metafields: $metafields) {
    deletedMetafields { ownerId namespace key }
    userErrors { field message }
  }
}

Variables:

{
  "metafields": [
    {
      "ownerId": "gid://shopify/Page/82760171623",
      "namespace": "the_same",
      "key": "test"
    },
    {
      "ownerId": "gid://shopify/Page/82760171623",
      "namespace": "the_same",
      "key": " test "
    }
  ]
}

The response was:

An unexpected error occurred while deleting metafields.

If I split this into two separate deletion requests, it works, but the bulk deletion via this mutation fails consistently.

Request for Help:

Does anyone know if there is a way to ensure that the response from the metafieldsSet mutation matches the actual data being created? The discrepancies between the returned data and what actually gets saved are problematic, especially in automated workflows where we rely on the response data.

Also, if anyone has found a way to successfully delete multiple metafields via metafieldsDelete without splitting them into separate calls, that information would be extremely helpful.

REST API isn’t a viable option for me, as it doesn’t support newer resource types like companies, etc.

Thanks in advance for any insights!

I’ve encountered additional issues with the metafieldsSet mutation and wanted to share them here to see if anyone else has faced similar problems or knows of any solutions.

Additional Issues:

  1. Case Sensitivity Issue When Creating Metafields:

If an entity already has a metafield with a key like "TEST" and you attempt to create a new metafield with a key in lowercase, like "test", the metafieldsSet mutation returns a response indicating that the metafield was successfully created with the key "test". It even returns the correct ID of the existing metafield.

However, when you subsequently query the list of metafields, you’ll find that the key was never actually changed.

This raises the question: how can we reliably know if the intended metafield was created as specified, rather than modifying an existing one? Making additional queries each time after creation to verify the data is not ideal, as it introduces additional requests, which we would prefer to avoid.

  1. Issues Retrieving Metafields with Similar Keys:

When retrieving metafields, there is an issue if you have metafields with keys like "test" and " test " (with leading or trailing spaces).
For example, using the following query:

query selectMetafield {
  page(id: "gid://shopify/Page/82760171623") {
    metafield(key: " test ", namespace: "the_same") {
      key
      namespace
      value
    }
  }
}

The response you get is for the metafield with the key "test", and there seems to be no way to access the metafield with the key that includes spaces if there is a similar key without spaces. This makes it impossible to retrieve the correct metafield using this API for keys that differ only by whitespace.

Suggested Improvements:

It might be helpful to strengthen the validation and API behavior in the following ways:

  1. Whitespace Handling: Enforce strict control over spaces in keys and namespaces—e.g., always trim leading and trailing spaces, and prevent double spaces within keys.
  2. Accurate Responses from API: Ensure that the metafields creation API returns the actual data as stored in the database, rather than returning placeholders that may not match reality.

If anyone has found a workaround or has any insights into how to address these inconsistencies, please share. These issues significantly complicate reliable use of the metafields API in production environments.