hero_image field causing missing images/build problems

[wu-lee]

Difficulties with a technical aspect of Gatsby means that the build can intermittently fail depending on essentially random factors. If the first article Gatsby sees in the build has this field set, it works as expected; if not, it can fail to build and/or there are no hero images (I don't recall the exact behaviour at the time of writing).

This issue has already had some attention but there is no resolution as yet. See

https://github.com/TransitionbyDesign/homemaker/commit/8f2c7304914160a723fd012bd93db658e4715af1 https://github.com/gatsbyjs/gatsby/issues/3344#issuecomment-989213202

[wu-lee]

This is a frustrating one, and is not new - it was a problem when the site was originally being worked on. I did think it was working but I think the recent content uploads have been triggering it again.

I've investigated fixing it, but I have not found a better solution than I did originally. The issue seems to be a known problem and any people are reporting it (see issue link above).

The dilemma is:

• Gatsby tries to infer the type of fields from the content it sees
• Specifically it seems to check the first content file it finds and base its inferences on that
• This seems not to be deterministic, even if the content hasn't changed. And of course it does change, too.
• So if Gatsby infers the right field type for hero_image, all is well
• If by chance it uses some content with the field missing or pointing to a non-existing file to make its inferences, things break
• There is a way to explicitly define what the fields are, but the obvious way to define hero_image as a File field does not get the same result as when (correct) inference occurs, and things break.

So, our case seems to be exacerbated by the fact that the hero_image field is an image file which needs to include functions provided by a Gatsby module gatsby_image to allow resized images to be generated: something is happening behind the scenes to change the way inference works, but I don't yet know what.

The best result seems to be to let Gatsby infer this field's type.

Consequently, until a solution is found - perhaps an explicit type specification which works - I recommend the following workaround:

• Make sure that every article on the site either has a valid hero_image or a valid youtube_url field

Some other problems to avoid:

• Do not use multi-frame gifs (like gifgit.gif), these seem not to work with gatsby_image. For now I've replaced that with a .png conversion of the first frame of gifgit.gif, called gifgit.png (and left gifgit.gif in the assets folder). See 179c5765f92a92632837aa257b511b207ebf6d80
• Do not use embeddable <iframe> HTML fragments in the youtube_url field. They don't work. I've corrected one case in oxford-s-development-sites.md, see 6dde8d33b1524fc694b973359c51a07971e09465

[wu-lee]

I think I may have found a solution, trawling the web and using some cargo-cult magic incantations. So instead of explicitly defining the hero_image field in gatsby-node.js like this (which gets an error "You can't use childImageSharp together with undefined.undefined" and no images):

 hero_image: File

Or leaving it undefined and therefore inferred - unreliably - by Gatsby, define it like this:

 hero_image: File @fileByRelativePath

That seems to do the job, but it's not very well documented!

Clues to this from: https://stackoverflow.com/questions/69738768

Which refers to: https://github.com/gatsbyjs/gatsby/issues/18271#issuecomment-547097964

This is now committed to the code, and seems to be working at the moment, but we should keep an eye on it, especially to check to see if custom_icon now works.