Possible change in Metafields query today

GraphQL Admin API Troubleshooting
1

Hi @Alan_G
A merchant just reported a sudden bug today in one area of the app that we haven’t changed in a long time and was working fine, which is strange. After some testing, I think the reason might be perhaps a small change to the Metafields query:

{
  productVariant(id: "gid://shopify/ProductVariant/...") {
    metafields(first: 30, keys: []) {
      nodes {
        key
        value
      }
    }
  }
}
# returns an empty array...

I think that, up until now, if the keys array was empty, it would simply return the first 30 results. Today, it returns an empty array. This broke something in the app which relied on falling back to the first results if no filter was specified. Can you confirm if there was such a change in this API around yesterday and today?

Just trying to assess whether this is us or if the API changed.

2

Hey @flavio-b - thanks for flagging this. I can’t say for sure, but one potential culprit could be the API version the shop/app is using.

I don’t see this specific behavior change documented in the release notes, but there were significant metafield-related changes in version 2025-01 that could have affected filtering logic (changelog notes here)

Can you let me know which API version your app is currently using? If you’re able to share an x-request-id as usual as well that would be super helpful so I can try replicating on my end here (let me know if if I can set up a DM on my end here if it’s easier to share that way)

Happy to get this looked into though for sure, hope to speak with you soon :slight_smile:

3

Hi Alan, sorry, the API version is 2025-07. We’ve been using since it July.

Our feature that pulls Metafields the way I described was probably released 2 years ago, so it’s worked pretty much the same throughout all the API versions.

It has always worked this way: If the keys array was empty, it would simply return whatever the first metafields were.

It was suddenly last week a merchant complained, I was confused since we hadn’t touched that module in while, and upon trying the Metafield query in GraphiQL, I noticed a change.

My first thought is the new behaviour might have been a “fix” to what was seen as bug, mid-cycle. To solve this, I simply removed the keys array from our variables when we have no specific keys to search for. However, I would still want to know if a change was done to the API, because it would be a breaking change, just so the devs are aware that this one slipped through.

I don’t have a request ID to share because it wouldn’t really show anything new. You can try it in GraphiQL and the result would be what I described.

4

Hey @flavio-b , thanks for clarifying. Just to confirm, this would have been the exact query you were running?

{
  productVariant(id: "gid://shopify/ProductVariant/variant-id-here") {
    id
    metafields(first: 30, keys: []) {
      nodes {
        key
        value
      }
    }
  }
}

I believe I was able to replicate this, but it’s possible this was undocumented behaviour as my understanding is that we did require specific key params to be passed when querying metafields.

Happy to look into this though to confirm expected behaviour for you and get this looked into. I just wanted to confirm the exact query you were using (as I copied what you had above). Hope to speak soon!

5

Yes, that’s the query. We pass the first and keys as GraphQL variables, but the result is exactly like yours.

The keys array would sometimes be empty, just like yours, but the query would still return the first 30 metafields, and we’d use that. It’s been like this for as long as I can remember. The change I’m referring to now is it suddenly returns an empty array when keys is empty.

My solution was to make our $keys variable optional, and don’t even include it in the variables argument when it’s empty. So, we just get the first 30.

It’s fine now, but I wanted to bring this to your attention because it indicates a potential change of behaviour mid cycle in the API. My guess is someone saw the old behaviour as a bug and “fixed” it, but we implicitly relied on that bug which was a feature for us :sweat_smile:

6

Thanks for confirming @flavio-b. Removing the keys param should work if you just want to have the first 30 metafields for a variant returned. I’m still going to look into whether this behaviour change was intentional for you though.

Out of curiosity though, could you share the use case for passing an empty keys array rather than just omitting the parameter? Was it just to keep the query structure consistent when you sometimes filter and sometimes don’t?

Either way, I’ll look into this on our end and get back to you. Thanks for flagging as always, speak soon!

7

I guess the reason was to keep the query simple. Our variables was built as a one-liner, with keys generated dynamically by a method: variables = {ids: ids, first: first, keys: keys}; # Ruby also allows {ids:, first:, keys:} in this case

There was not much planning. I simply noticed it would fetch the first metafields anyway if for some reason there were no specific keys to search for, which is exactly the behaviour I needed.

Now, I build variables in two steps:

variables = {ids:, first:}
variables[:keys] = keys if keys.any?

There are ways to make it a one-liner again but I prefer this format. In any case, it’s all fine. The problem was more the surprise of the change, not the change itself.

1 Like