BUG - fileCreate Mutation returning no errors when invalid originalSource url submitted

[Jason27]

If you pass an invalid $src pointing non-existing image online, graphQL fileCreate mutation will return a response exactly like one that was successful. It even includes an invalid graphQL ID. See below.

$files = [
    "files" => [
        "alt" => "fallback text for an image 1",
        "originalSource" => $src
    ]
];

mutation fileCreate(\$files: [FileCreateInput!]!) {
            fileCreate(files: \$files) {
                files {
                    alt
                    ... on MediaImage {
                        id
                    }
                }
                userErrors {
                    field
                    message
                }
            }
        }

You will get this returned which looks like it went thru correctly

array(1) {

  ["fileCreate"]=>

  array(2) {

    ["files"]=>

    array(1) {

      [0]=>

      array(2) {

        ["alt"]=>

        string(28) "fallback text for an image 1"

        ["id"]=>

        string(39) "gid://shopify/MediaImage/21806830387252"

      }

    }

    ["userErrors"]=>

    array(0) {

    }

  }

[jon551]

Hi Jason27,

Thanks for your post. This is expected behaviour because when the fileCreate mutation is run for a remote image the MediaImage's MediaStatus gets created in an 'Uploaded' state, and is later updated once the attempt to fetch the remote image is complete with the results of the attempt.

The list of different states for MediaStatus is here: https://shopify.dev/api/admin-graphql/2022-07/enums/MediaStatus

A good way to quickly see the 'Uploaded' state is to add the 'status' attribute under the '... on MediaImage' part of the mutation you shared, like this:

mutation fileCreate($files: [FileCreateInput!]!) {
  fileCreate(files: $files) {
    files {
      alt
      ... on MediaImage {
        id
        status
      }
    }
    userErrors {
      field
      message
    }
  }
}

More info: [Checking whether media is ready to display - Shopify Dev Docs]

Hope you have a great day,

[Jason27]

Sorry I just tested this again with a valid and invalid URL, and both responses returned the same status (UPLOADED).

array(1) {
  ["fileCreate"]=>
  array(2) {
    ["files"]=>
    array(1) {
      [0]=>
      array(3) {
        ["alt"]=>
        string(28) "fallback text for an image 1"
        ["id"]=>
        string(39) "gid://shopify/MediaImage/21811232800820"
        ["status"]=>
        string(8) "UPLOADED"
      }
    }
    ["userErrors"]=>
    array(0) {
    }
  }
}

[jon551 · Accepted solution]

Hi Jason27,

Yes 'UPLOADED' is currently the earliest MediaStatus so it's the default that will show when the media record is created, then it will update to 'FAILED' if the system tries to pull the image from the URL and can't get it, or 'PROCESSING' and then 'READY' if everything works out.

This initial status message of 'UPLOADED' could be more clear in this particular type of use case so we're submitting a report to our internal teams to see if it can be clarified, however changing that would be a breaking change for implementations watching for that value so that will need to be considered.

Checking if the acquisition of the image from the remote URL and the related file processing was successful can be done with a followup query for the status using the object id that was returned, and requesting mediaErrors.details can provide a more verbose error message if there was a problem. For example:

query {
	node(id: "gid://shopify/MediaImage/21811232800820") {
		id
		...on MediaImage {
			status
			mediaErrors {
				details
			}
		}
	}
}

Hope you have a great day

[Jason27]

Hi Jon, thanks for the workaround, but wouldn't it just be simpler to return a userError if the URL is invalid or 404 ? Then you don't need to update the 'status' field. Cheers

[jon551]

Hi Jason27,

Thanks for your reply. It's not known if the URL will be a 404 until the remote server has been contacted which can take a variable amount of time and would delay the initial response, so the initial reply is accepting the payload of data and then it gets processed more later to help keep the system faster overall.

Hope you have a great day,

[chendongyang]

Do you know the question as below?

The HMAC digest  by java differs from your generated as Verifying the webhook to authorize our app using OAuth, please check our annexes,

[Jason27]

I'm not sure how this is an accepted solution... since there doesn't not appear to be any way to query a mediaImage ID using the Files endpoint. You can keep querying for the filename every second until it appears and then returns READY, but if it fails, it never returns anything. Am I missing something? Is there a way to query any generic media image using the gid, whether its a FILES or any other type?