Cannot delete app-data metafields

GraphQL Admin API Troubleshooting
1

My app stores some data in app-data metafields. When the data is no longer needed (i.e. during uninstall), in attempt to the keep the merchant’s store clean, I would like to be able delete any data in the app-data metafields, and also delete the app-data metafields themselves.

According to the documentation, app-data metafields are created using the metafieldsSet mutation, are owned by the app (or API_PERMISSION enum type), and do not have a definition (unlike metafields for PRODUCT, PRODUCTVARIANT, etc…)

So when I try to delete an app-data metafield using the metafieldsDelete mutation as follows:

mutation deleteAppMF($mf: [MetafieldIdentifierInput!]!) {
  metafieldsDelete(metafields: $mf) {
    deletedMetafields {
      key
      namespace
      ownerId
    }
    userErrors {
      field
      message
    }
  }
},
{
  variables: {
    "mf": [
      {
        "key": {key1}
        "namespace": "$app:{appTitle}",
        "ownerId": {appInstallationId}
      }
    ]
  }
}

I get the following error:

"metafieldsDelete": {
  "deletedMetafields": [],
  "userErrors": [
    {
      "field": [
        "metafields"
      ],
      "message": "Access to this namespace and key on Metafields for this resource type is not allowed."
    }
  ]
}

I am running this mutation from my local dev GraphiQL web interface (g from shopify CLI) which has the same access scopes as my app. In reviewing the API access scopes, there is no access scope specific to the Metafield object, so I’m puzzled by this error message.

Interestingly enough, the deprecated metafieldDelete mutation (tested with API 2024-10) successfully deletes the app-data metafield by specifying the metafield’s ID (not the ownerId as with an app-data metafield).

Is this a gap with the new metafieldsDelete mutation?

1 Like
2

Hey Steve,

It does appear you’re doing things correctly, I’ve reached out to the custom data team to look into this further.

3

Having the same issue right now. Also because we can not delete it entirely, we cannot create a definition with same namespace and key again, and now because I have it on READONLY for Merchants we have a metafield there that is blocked forever.

[
  {
    field: [
      "definition",
    ],
    message: "Definition type does not support migration of existing metafields.",
    code: null,
  },
]
4

Any updates from the custom data team?

5

Following up for any updates. Using the deprecated metafieldDelete mutation in the interim as a workaround.

6

Have asked the relevant team about this one again Steve.

7

Just to update - our team are working on a fix for this

8

Thanks for the update. Please let me know if/when you need to test the fix.

10

I have the same issue. Hoping for the quick fix!

Will fall back to deprecated metafieldDelete for now as @Steve_Karan suggests.

11

@Liam-Shopify Following up… Any updates/progress on implementing/pushing a fix?

Curious to know if it has to do with app-data metafields and access controls. “Regular” metafields (product, variant, etc…) have access controls in their definition. App-data metafields don’t have a definition; they’re just created with metafieldsSet

12

Does the issue change at all if you create the appInstallation metafield WITHOUT the $app prefix?
i.e. checking if this is a bug due to the discussed behavior:

These[app-data mfs] don’t support a reserved namespace formatting with a prefix, $app
Solved: GraphQL bug while creating app owned metafield - Shopify Community
also see Solved: App Metafields - Shopify Community [appIntallation mfs query fails after metafieldset]

If so it’s a historical bug? So gotta wait for a fix for previous install but also avoid repeating it.

13

Just in case this does mean metafield-definitions and not re-defining a metafield.
Isn’t it also app-data metafields aren’t meant to have metafield definitions; because ~access controls~ permissions aren’t needed as only the app can access them through the appInstallation || currentAppInstallation object(s).
Unlikes “app-owned” metafields which have sdefault that have to be overridden with access permissions.

14

@PaulNewton ,

Thanks for the updates. The posts you shared were from 2023, so we know things can certainly change over time, especially between API versions.

I did some further testing, and experienced some rather inconsistent results:

  1. Create an app-data metafield with the metafieldsSet mutation, specifying a namespace as $app:namespace.

    The app-data metafield is created successfully. I can read and write data to this app-data metafield, but cannot delete it with metafieldsDelete mutation due to the “Access” error.

  2. Create an app-data metafield with the metafieldsSet mutation, omitting a namespace. As per the metaieldsSet documentation for the namespace field, If omitted the app-reserved namespace will be used.

    The app-data metafield is created successfully with a app-reserved namespace defaulting to app--{appinstallationId}. I can read and write to this metafield, but cannot delete the metafield with the metafieldsDelete mutation when specifying the namespace as app--{appInstallationId} or $app. The metafieldsDelete mutation produces the same “Access” error from Test 1.

  3. Create an app-data metafield with the metafieldsSet mutation, specifying a namespace as namespace (i.e. no app-reserved prefix)

    The app-data metafield is created successfully without an app-reserved namespace. I can read and write to this metafield, and can delete it with the metafieldsDelete mutation.

Based on your feedback, it seems app-reserved prefixes are supported when creating the app-data metafield, but not when deleting them with the new metafieldsDelete mutation. However, app-data metafields with an app-reserved prefix can be deleted with the deprecated metafieldDelete mutation using API version 2024-10 and earlier.

Therefore, I believe the inability to delete an app-data metafield with an app-reserved prefix with the metafieldsDelete mutation is a bug that requires a fix.

1 Like
15

:star_struck: Great detective work :detective:
I literally just hit the access bug too in retesting metafieldsDelete when trying to see if it can act as a bulk delete when using it without any namespace, or only the $app prefix as the namespace. But also the full prefix doesn’t allow access. Still have to loop through those with keys too.
:confused: Part of this is also I’m not 100% clear on what the data retention is when an app is uninstalled if all metafields are nuked with it or not.
e.g. the following inputs get the "message": "Access to this namespace and key on Metafields for this resource type is not allowed."

{
      ownerId: "gid://shopify/AppInstallation/1234567890"
      namespace: "",
      key:""
}

or

{
      ownerId: "gid://shopify/AppInstallation/1234567890"
      namespace: "$app",
      key:""
}

   {
      namespace: "app--54321"
      key: ""
      ownerId: "gid://shopify/AppInstallation/1234567890"
   }

There’s also whether any of this is a side-effect of the yet to happen April 1 change coming for the simplified perm systems for custom data which should be the last phase of this areas switch over removing some outputs auto-migrating permissions. Simplifying how metafield and metaobject permissions work - Shopify developer changelog. though i’ve only tested unstable not 2025-04 because it’s not in my test apps graphiql for some reason

16

Hey folks - update on this: you should be able metafieldsDelete to delete app-data metafields now.

17

Thanks for the update. Lost track of this as I got side-tracked with other things…

I’ll test the metafieldsDelete mutation and will reply back with my results.

18

Let us know if you’re still seeing an issue!

19

Thanks @Liam-Shopify. I just tested the metafieldsDelete mutation using the local GraphiQL interface with API 2024-10 with the same code provided at the beginning of this thread. It succeeded without the “Access” error.

I also confirmed that the app-data metafield was deleted.

Thanks for following this through to resolution!

20

TL;DR can’t manually delete app metafield from admin panel with collaborator access.

Not exactly about this thread’s API topic, but how do you do this manually? We didn’t have deleteMetafield setup because I thought it was automatic on uninstall and a customer asked us to remove it for them. They gave us collaborator access and I can see our metafield in “Custom Data” but there’s no option to delete. I tested by creating a new metafield and I was able to delete it from the “More Actions” menu that shows up.

21

If the app created metafield under reserved namespace, then the only way to delete is reinstalling the app and deleting via API using app access token. No one else can delete metafields under app namespace.