Calling __refresh while refreshing

Description

Our team is leveraging the Gatsby refresh endpoint (ENABLE_GATSBY_REFRESH_ENDPOINT) for development purposes. The amount of time to build/refresh has increased over time. We are wanting to use a service that will make a POST call to __refresh on demand. The problem that we are encountering is that if you make the POST call in the middle of a refresh then unexpected behavior starts to occur and eventually the dev server crashes. It would be nice to have some way to either offer some kind of throttling or at least have a way to know if we are in the middle of a refresh. (with the latter at least a custom endpoint can be created)

Our understanding was that it did not behave like this before (2.16.5) and if this were to occur Gatsby would wait until the existing refresh would finish.

Steps to reproduce

Make a POST call to __refresh while it’s refreshing.

Expected result

Expected behavior.

Actual result

Query failures, crashes, etc.

Environment

(This also occurs in Windows)

EDIT: Updated gatsby to 2.18.21 and it is still an issue.

  System:
    OS: macOS Mojave 10.14.6
    CPU: (8) x64 Intel(R) Core(TM) i7-3615QM CPU @ 2.30GHz
    Shell: 5.3 - /bin/zsh
  Binaries:
    Node: 12.12.0 - /usr/local/bin/node
    Yarn: 1.19.1 - /usr/local/bin/yarn
    npm: 6.11.3 - /usr/local/bin/npm
  Languages:
    Python: 2.7.16 - /usr/local/bin/python
  Browsers:
    Chrome: 79.0.3945.117
    Firefox: 72.0
    Safari: 13.0.4
  npmPackages:
    gatsby: ^2.18.15 => 2.18.15
    gatsby-background-image: ^0.9.11 => 0.9.11
    gatsby-image: ^2.2.4 => 2.2.36
    gatsby-plugin-lodash: ^3.1.2 => 3.1.18
    gatsby-plugin-manifest: ^2.2.1 => 2.2.33
    gatsby-plugin-polyfill-io: ^1.1.0 => 1.1.0
    gatsby-plugin-prefetch-google-fonts: ^1.4.3 => 1.4.3
    gatsby-plugin-react-helmet: ^3.0.12 => 3.1.18
    gatsby-plugin-remove-serviceworker: ^1.0.0 => 1.0.0
    gatsby-plugin-robots-txt: ^1.5.0 => 1.5.0
    gatsby-plugin-sass: ^2.1.12 => 2.1.26
    gatsby-plugin-sharp: ^2.2.3 => 2.3.7
    gatsby-plugin-sitemap: ^2.2.9 => 2.2.24
    gatsby-plugin-styled-components: ^3.0.7 => 3.1.16
    gatsby-plugin-typescript: ^2.0.15 => 2.1.22
    gatsby-plugin-webpack-bundle-analyser-v2: ^1.1.5 => 1.1.8
    gatsby-source-filesystem: ^2.1.2 => 2.1.42
    gatsby-transformer-sharp: ^2.2.1 => 2.3.9
  npmGlobalPackages:
    gatsby-cli: 2.6.7

[xavivars]

Even a simple “reject” would be better that the current behavior…

[pieh]

Yes! Let’s implement queue for that! There also other places I wanted simple queue like that (particularly our redux state persistence which is now just debounced)