gatsby: createRemoteFileNode crashes when url doesn't have an extension

Description

calling createRemoteFileNode with an url (https://fakeimg.pl/300x300/?text=2) without an extension crashes.

Unexpected error value: "failed to process https://fakeimg.pl/300x300/?text=2\nError: ENOENT: no such file or directory, stat '.../.cache/gatsby-source-filesystem/7a1221ea4c61551f928908dd873a3738/300x300'"

I think it has something to do with how the caching is handled.

Steps to reproduce

use createRemoteFileNode to create remote file nodes from an url without an ext
use the remote file node in eg. sharp-image
the first build goes through
all builds afterwards crash

Environment

  System:
    OS: Linux 5.3 Ubuntu 18.04.3 LTS (Bionic Beaver)
    CPU: (8) x64 AMD Ryzen 5 2500U with Radeon Vega Mobile Gfx
    Shell: 4.4.20 - /bin/bash
  Binaries:
    Node: 13.9.0 - /usr/bin/node
    Yarn: 1.22.0 - ~/bin/yarn
    npm: 6.13.7 - /usr/bin/npm
  Languages:
    Python: 2.7.15+ - /usr/bin/python
  Browsers:
    Firefox: 73.0.1
  npmPackages:
    gatsby: ^2.19.21 => 2.19.24
    gatsby-cli: ^2.9.0 => 2.9.0
    gatsby-image: ^2.2.41 => 2.2.42
    gatsby-plugin-graphql-codegen: ^2.2.2 => 2.2.3
    gatsby-plugin-react-helmet: ^3.1.21 => 3.1.22
    gatsby-plugin-react-svg: ^3.0.0 => 3.0.0
    gatsby-plugin-sass: ^2.1.27 => 2.1.29
    gatsby-plugin-sharp: ^2.4.5 => 2.4.5
    gatsby-source-filesystem: ^2.1.48 => 2.1.48
    gatsby-transformer-json: ^2.2.26 => 2.2.26
    gatsby-transformer-sharp: ^2.3.14 => 2.3.16

Repro

https://github.com/chpio/gatsby-remote-wo-ext commit https://github.com/chpio/gatsby-remote-wo-ext/commit/8d898f6915221495e092798e5bfcbacdd3faaf30

About this issue

Original URL
State: closed
Created 4 years ago
Reactions: 1
Comments: 16 (7 by maintainers)

Most upvoted comments

@vladar Seems like FileType.fromFile() should do the job?

ynnoj on Oct 16, 2020

Why should i do that? The doc even says, that it can be passed in:

Finally, the name and the extension can be explicitly passed
to pass it in i need to know it, but i do not. My first workaround was to just pass in “.jpeg”, but then i needed the actual extension (to generate the download argument on an <a> tag)
a crash is clearly a bug

chpio on Mar 3, 2020

Ok, what are you saying?

If the url does not contain an extension, we use the file-type package to infer the file type.

That works for the 1. build, but not for following builds. The cache file gets created with an extension, but the following builds try to read the file from cache without an extension and crash due to a read on a non-existing file.

chpio on Mar 2, 2020

Yup, looks like it should do the trick!

vladar on Oct 16, 2020