I’m running a bulk operation to fetch products, and I noticed that some metafields do not get returned in the resulting file.
I isolated the product query to return only the relevant metafield (one of those that are missing), for a product that has a valid a value for it (I double and triple checked) and still it’s not returning anything,
for example this graphql using the regular product query:
query ProductWithoutVariants($id: ID!){
product(id: $id) {
id
mf: metafield(key: "REDACTED", namespace: "custom") {
value
jsonValue
type
}
}
}
Will correctly return the metafield.
While the bulk operation below (using the same product ID and metafield):
mutation {
bulkOperationRunQuery(query: """
products(query: "(id:REDACTED)") {
edges {
node {
id
metafields(first: 200, keys: ["custom.REDACTED"]) {
edges {
node {
id
definition {id}
namespace
key
jsonValue
type
}
}
}
}
}
}""") {
bulkOperation {
id
status
}
userErrors {
field
message
}
}
}
and the resulting jsonl file without the requested metafield:
{"id":"gid:\/\/shopify\/Product\/REDACTED"}
The bulk operation is the following: 5396624048264
Can I get support from the dev team directly on the forum?
Hey @Soufiane_Ghzal - thanks for reporting this. I think we’ll have to dig into this a bit more internally on our end here, but just out of curiosity, if you make the bulk op query without the key value included, does the metafield you want show up?
Just want to see if the issue is with the key param in the query specifically. Hope to hear from you soon!
Hi @Alan_G thanks for reaching out and confirming you’re on it.
You might have been notified already but just to make sure you know: got in touch with the support in the meanwhile and they said they escalated, so there is probably an internal ticket or something for it.
Also, could you please confirm that you’ve found there is something wrong with the bulk operation itself, and I’m not making a careless mistake with it?
I tried with the namespace only:
metafields(first: 200, namespace: “custom”)
And I confirm it’s working, the metafields that are missing when using just the key are now returned.
Regarding the faulty metafield. if you have access to the bulk operation I communicated, you might have seen that already, but the metafield key has the form: S3_aaa_bbb_ccc (capital S and a number as the first 2 chars)
Regarding the faulty metafield. if you have access to the bulk operation I communicated, you might have seen that already, but the metafield key has the form: S3_aaa_bbb_ccc (capital S and a number as the first 2 chars)
The capital is the key of the problem.
For some reasons when I run the query using only the namespace, the metafield I got has a capital letter, but when I list the metafield definitions with a query like this one:
metafieldDefinitions(
first: 200,
ownerType: XXX,
query: YYY,
after: ZZZ
) {
pageInfo {
hasNextPage
endCursor
}
nodes{
id
namespace
key
name
access {admin}
type {
name
}
ownerType
validations {
name
value
}
}
}
It returns the same metafield key without the capital on the S
With that being set. I tried to run again the bulk operation and use the capital S:
metafields(first: 200, keys: ["custom.S3_xxx"]) {
And it Worked
However there is an inconsistency somewhere here:
The definition returns no capital
The bulkoperation keys param is case sensitive (breaking when we use the key from the definition)
The regular product query keyparams seems to be insensitive
Now that we were able to identify the issue I need to know if you are able to ship a fix for this quickly or will we have to wait for a while (or is it unsure)?
I’d appreciate a direct and honest answer to this question as it’s how I will decide if I ship a workaround in my app or wait for a resolution.
Hi @Alan_G I’m sorry to bother you, but because I was able to pin-point the origin of the problem, I want to make sure you haven’t missed my answer here.
Thank you in advance
PS: I’d like to suggest that it would be really helpful if we had a bug-tracker or something like that for these things, as I feel it’s not easy to escalate real bugs and have a good tracking of them with the resources at our disposal.
Hey @Soufiane_Ghzal, no worries at all, thanks for flagging this again, it’s super helpful. This does appear to be an issue on our end and we’re tracking internally. For now, your workaroundto query by namespace only (without the keys param) and handle the key filtering client-side is the best method. Not ideal, but it should unblock you. I’ll keep you updated as we look into this. Can’t guarantee a turnaround time, but will keep my eyes on this.
For bug reports, I definitely agree it would be ideal in some circumstances to have a public tracking system for them. Again, I can’t guarantee anything there, but I’m happy to pass along that feedback for sure.
I’ll update you here when I have more from the team!
Hi @Alan_G thanks for the follow up and the workaround. However, we can’t afford querying without specifying the keys. We observe slow bulk operations with a given list of metafields, and the bulk operations are already the bottleneck of the app. If we were querying all metafields using the namespace only it would become a lot slower.
Instead we will hard code something for the specific shop and metafield affected.
To do that the right way I’d like to know if, in the first place, it is expected to see an uppercase character in a metafield key and whether you already know how you intend to fix it (will the capital character remain or not)?
Hey @Soufiane_Ghzal - sorry for the wait here. We’re still looking into whether the uppercase key or the lowercased version from metafieldDefinitions is the correct one, so I can’t say definitively yet which direction the fix will go.
For your workaround, I’d recommend using the actual casing from the metafield itself (what you get back when querying by namespace) rather than what metafieldDefinitions returns — that should be the safest bet regardless of how we resolve this. I’ll keep you posted as I hear more, apologies for the wait, I realize this isn’t the most ideal answer.
correctly return the metafield.
without the requested metafield: