Build failing with ProbeError: unrecognized file format

I have a gatsby site which is using Netlify CMS along with large media

If I run npm run build locally, the site builds without issue, and I can then run gatsby server to view the site, again without issue.

When I deploy to Netlify, the build is also running npm run build, but it fails at the same point every time:

8:16:06 PM: error There was an error in your GraphQL query:
8:16:06 PM: unrecognized file format
8:16:06 PM:    5 |       seo_description
8:16:06 PM:    6 |       seo_title
8:16:06 PM:    7 |       title
8:16:06 PM:    8 |       gallerysections {
8:16:06 PM:    9 |         landscape_image_video_gallerysections_vimeo_video_id
8:16:06 PM:   10 |         landscape_image_video_gallerysections_video {
8:16:06 PM:   11 |           publicURL
8:16:06 PM:   12 |         }
8:16:06 PM:   13 |         landscape_image_video_gallerysections_image {
8:16:06 PM:   14 |           childImageSharp {
8:16:06 PM: > 15 |             gatsbyImageData(placeholder: NONE)
8:16:06 PM:      |             ^
8:16:06 PM:   16 |           }
8:16:06 PM:   17 |           publicURL
8:16:06 PM:   18 |         }
8:16:06 PM:   19 |         type
8:16:06 PM:   20 |       }
8:16:06 PM:   21 |     }
8:16:06 PM:   22 |   }
8:16:06 PM:   23 | }
8:16:06 PM:   24 |
8:16:06 PM: File path: /opt/build/repo/src/templates/gallery.js
8:16:06 PM: Url path: /gallery/2022/6/25/look-deeper/
8:16:06 PM: Plugin: none
8:16:06 PM: 
8:16:06 PM: 
8:16:06 PM:   ProbeError: unrecognized file format

Im including the package-lock file in the repo, and my package.json file looks like:

"@babel/eslint-parser": "7.18.2",
    "@gatsbyjs/reach-router": "1.3.7",
    "@mailchimp/mailchimp_marketing": "3.0.75",
    "@vimeo/player": "2.17.0",
    "babel-preset-gatsby": "2.17.0",
    "dotenv": "16.0.1",
    "gatsby": "4.17.1",
    "gatsby-link": "4.17.0",
    "gatsby-plugin-image": "2.17.0",
    "gatsby-plugin-manifest": "4.17.0",
    "gatsby-plugin-netlify": "5.0.0",
    "gatsby-plugin-netlify-cms": "6.17.0",
    "gatsby-plugin-offline": "5.17.0",
    "gatsby-plugin-react-helmet": "5.17.0",
    "gatsby-plugin-react-svg": "3.1.0",
    "gatsby-plugin-robots-txt": "1.7.1",
    "gatsby-plugin-sass": "5.17.0",
    "gatsby-plugin-sharp": "4.17.0",
    "gatsby-remark-copy-linked-files": "5.17.0",
    "gatsby-remark-images": "6.17.0",
    "gatsby-remark-relative-images": "0.3.0",
    "gatsby-source-filesystem": "4.17.0",
    "gatsby-transformer-remark": "5.17.0",
    "gatsby-transformer-sharp": "4.17.0",
    "lodash": "4.17.21",
    "lodash-webpack-plugin": "0.11.6",
    "mailchimp-api-v3": "1.15.0",
    "netlify-cms-app": "2.15.72",
    "netlify-cms-media-library-uploadcare": "0.5.10",
    "prop-types": "15.8.1",
    "react": "18.2.0",
    "react-dom": "18.2.0",
    "react-helmet": "6.1.0",
    "react-lazy-load-image-component": "1.5.4",
    "sass": "1.53.0"

The image its failing on is just a JPG, so it should work with Gatsby image, but Ive also tried several other images of type JPG and PNG, to which I get the same error.

Any idea why this would be failing within Netlify but not when I run build locally?

I’d start off by syncing your local development with the live production environment, there might be some differences between node/npm versions etc:

I don’t use Gatsby but I was thinking: Does gatsbyImageData expect an extension (.jpg) instead of a NLM transform? .jpg?nf_resize=fit&w=300&h=400)?

I’ve added my node version which is 14.16.0 to the netlify.toml file and deployed again, but still the same error.

I also tried to clear cache and deploy again in netlify but again same error.

Build still working locally.

If I remove this particular image and path from the MD file and the reference in the graphql, the build passes, and I have other JPG’s in the CMS, so I don’t believe it has anything to do with the NLM transform, assuming this would appear for all images.

Getting exactly same error for me. Local build works fine but get it failed on Netlify.

Considering you’re using Netlify Large Media, this is expected. Netlify Large Media cannot be used for build-time transformations since the images don’t exist in your repo.

@hrishikesh I didn’t see anything about Gatsby and netlify large media not working together in the docs. If Gatsby pulls the image down on build, can it not grab the image from the reference? In the same way it can from an external source. I’d assumed that was the case

How are you doing that? Are you actually fetching the image from the URL? If you’re trying to access directly from the repo, it’s expected to fail.

@hrishikesh its the build that is failing to pull down the images, but if the Gatsby image plugin doesn’t work with Netlify large media, why does it work when I build locally?

Sorry if I’m being a n00b, this is my first time trying to use Netlify CMS with a Gatsby project, I normally use Dato, but thought Netlify CMS was worth a go, and apart from this issue, so far Im really impressed!

This may all come down to a set up issue, I followed the instructions here to set up large media, but looking now all of the images I have uploaded via the CMS are still in the git repo, and I can only see some of these images when I visit the large media settings page with Netlify admin. It was my understanding that I should be able to see all of the images within Netlify admin, and within the repo I would only see a reference to the image. Is this not the case? Or is this not been set up correctly?

Also what should the path to the image be in the markdown files Netlify CMS creates? At the moment its just adding the relative path to the image, but should this also be a reference to the file instead?

This boils down to the explanation of what Large Media is and how it works.

When you use Large Media, Git will only store text pointers of your actual files in your repo. So, if you go to your repo on GitHub, you most likely won’t see any images there. There would be small, a few hundred-bytes files instead. Those files will contain metadata to locate the actual files that Netlify has stored for you on Netlify Large Media.

When you build locally, those files are available on your device - it will obviously work. When you build on Netlify, Netlify only has access to the files in your repo - in this case, those small, text files and not the images. That’s not a valid image file and thus, Gatsby (or any other tool) cannot process those as images.

This is exactly why Netlify Large Media offers run-time image transformation to resize images directly when requesting them. In your markdown file, you should reference the images directly from the path, relative to your site’s base and you should adapt your Gatsby code to not try to process these images.

@hrishikesh I still don’t understand why we couldn’t use the text pointers added by large media, to grab the images from Netlify on gatsby build? I mean I can grab images from external URLs without issue, I would assume this would work in a similar way.

Would this be the same case for next.js? Would it not be worth mentioning this in the docs, if I knew it didn’t work for Gatsby I wouldn’t have implemented it.

Either way we have decided to use the CDN route with cloudinary.

That’s more like Gatsby’s limitation than Netlify’s I’d believe.

External URLs return an image, text pointers don’t.

Here’s more on how Git LFS works:

Specifically:

Git LFS uses pointers instead of the actual files or binary large objects (blobs).

So, instead of writing large files/blobs to a Git repository, you write a pointer file, and the files/blobs themselves are written to a separate server. Plus, with Git LFS, multiple servers can be used.

Like I said, the files don’t exist in your repo, it’s up to the tool to add a way to request these files from Netlify.

For anything that tries to access files from your repo.

Thanks @hrishikesh for taking the time to explain this to me.

I’ve moved my images to couldinary, but recently I discovered the following plugin, which I think would have fixed the issue I was having: https://www.gatsbyjs.com/plugins/gatsby-source-netlify-lfs/ In case anyone else stumbles across this, I haven’t tested with this plugin, but I’d try this first before moving to a CDN or external resource

1 Like

Thanks for coming back and sharing, @cdennington :tada: