Images on our site are suddenly broken

steve-tranont · November 14, 2023, 9:10pm

Here is our site: https://deploy-preview-459--devtranont.netlify.app/

Most (not all) of the images on our site are broken

This started today when we ran a build/deploy. There weren’t any code changes. We use Strapi on the back end, which I initially thought was the problem, but somebody just made a few text changes and triggered a build. I tried building a preview version of the site that pulls from our strapi dev, which hasn’t been touched, and the same thing happened.

In the browser console, we’re getting these errors.

It seems like the problem is related to this ipx package.

We tried installing the ipx package in the project, this didn’t help.

I’m not sure what logs or build settings to post. If they will help please tell me what to get.
I tried pasting in the logs but they’re too big.

jon.pekkarinen · November 14, 2023, 9:39pm

Having the same issue. Just started today. Images are broken on all new builds. Images on old builds look fine. Checked the logs and getting this:

Nov 14, 02:46:25 PM: 2cef8a3a ERROR Invoke Error {"errorType":"TypeError","errorMessage":"(0 , fs_1.default) is not a function","stack":["TypeError: (0 , fs_1.default) is not a function"," at loadSourceImage (/var/task/node_modules/@netlify/ipx/dist/http.js:128:34)"," at async handler (/var/task/node_modules/@netlify/ipx/dist/index.js:132:64)"]}

mikey_u · November 14, 2023, 11:00pm

Same!

{
  "errorType": "TypeError",
  "errorMessage": "(0 , fs_1.default) is not a function",
  "stack": [
    "TypeError: (0 , fs_1.default) is not a function",
    "    at loadSourceImage (/var/task/node_modules/@netlify/ipx/dist/http.js:128:34)",
    "    at async handler (/var/task/node_modules/@netlify/ipx/dist/index.js:132:64)"
  ]
}

Assuming the latest release is being used, then this is the dist file:
https://cdn.jsdelivr.net/npm/@netlify/ipx@1.4.5/dist/http.js

So the error is coming from this line:

github.com

netlify/netlify-ipx/blob/v1.4.5/src/http.ts#L174


      
          }
          
          export async function loadSourceImage ({ cacheDir, url, requestEtag, modifiers, isLocal, requestHeaders = {} }: SourceImageOptions): Promise<SourceImageResult> {
            const fileCache = join(cacheDir, 'cache')
            const metadataCache = join(cacheDir, 'metadata')
          
            await ensureDir(fileCache)
            await ensureDir(metadataCache)
          
            const metadataStore = createStorage({
              driver: fsDriver({ base: metadataCache })
            })
            const cacheKey = String(murmurhash(url))
            const inputCacheFile = join(fileCache, cacheKey)
          
            await markUsageStart(metadataStore, cacheKey, inputCacheFile)
            await maybePruneCache(metadataStore)
          
            function finalize () {
              return markUsageComplete(metadataStore, cacheKey)
            }

If they’re not using a release, but just the latest commit to the main branch, then the line would be here (no changes to that file since v1.4.5):

github.com

netlify/netlify-ipx/blob/85c76cc/src/http.ts#L174


      
          }
          
          export async function loadSourceImage ({ cacheDir, url, requestEtag, modifiers, isLocal, requestHeaders = {} }: SourceImageOptions): Promise<SourceImageResult> {
            const fileCache = join(cacheDir, 'cache')
            const metadataCache = join(cacheDir, 'metadata')
          
            await ensureDir(fileCache)
            await ensureDir(metadataCache)
          
            const metadataStore = createStorage({
              driver: fsDriver({ base: metadataCache })
            })
            const cacheKey = String(murmurhash(url))
            const inputCacheFile = join(fileCache, cacheKey)
          
            await markUsageStart(metadataStore, cacheKey, inputCacheFile)
            await maybePruneCache(metadataStore)
          
            function finalize () {
              return markUsageComplete(metadataStore, cacheKey)
            }

Either way, looks like unstorage@^1.0.0 is resolving to 1.9.0, according to yarn.lock, which also shows that Yarn 1 is being used – whoa, kickin’ it old school!

Looks like unstorage v1.10.0 was released about 5 hours ago: Release v1.10.0 · unjs/unstorage · GitHub

Related docs: Node.js Filesystem · 💾 Unstorage

mikey_u · November 15, 2023, 12:53am

I opened a support ticket around 3:06pm PT, I received a response at 4:27pm PT:

We’re investigating it right now. We don’t have a reproduction case but think we might have fixed it. Would you be able to re-deploy your site and let us know if you still see the problem?

I redeployed, but the issue persists.

5:10pm, was asked to try again, the issue persists. Apparently they’ve resolved it for others, maybe my setup is funky in some way. Wouldn’t be surprising, just migrated the affected site to Netlify today.

steve-tranont · November 15, 2023, 4:08pm

The issue has been fixed for us. Good luck @mikey_u .

mikey_u · November 15, 2023, 6:24pm

That’s great! I created a new site from scratch (pnpm create t3-app@latest), added an image using next/image, and I didn’t encounter the issue (image loaded fine using , so there must be something unusual with the migrated repo. If I figure it out, I’ll share here, just in case someone stumbles across this thread in the future. However I’m triggering it, would be ideal to have a more useful error.

hrishikesh · November 16, 2023, 1:19pm

This was a temporary issue on our end which has since been resolved.

jon.pekkarinen · November 16, 2023, 3:11pm

Latest build is working. Thanks!