fix(gatsby): revert #19664 fix duplicate runs in develop mode #20836
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Reverts #19664 because it exposed a timing problem in promises ultimately leading to
gatsby develop
triggering a number of redundant rebuilds.At the core to this is listening to the api queue drain event,
API_RUNNING_QUEUE_EMPTY
, which before would only fire once. After this change, that event fires three times for the same sequence of events (a file changing).The reason seems to relate to the difference in how BlueBird resolves its promise vs doing it natively. In this case, changing the promise led to the queue draining before the next api call had a chance to fill it up again. And again. So each of these calls would now see an empty queue, fill it, completely run (in pseudo sync time), and drain the queue again. Each call would lead to announcing the start and drain of the api queue.
Over in
gatsby develop
we were listening for the drain event as a way of debouncing a refresh-in-progress.We've triaged this and tried to come up with a better solution without having to do a revert but ultimately there's not a trivial way of getting what we want. We need to consider a proper state machine model, where api calls fall within a higher level task description, to be able to "wait" for a current update to finish. Right now such structure does not exist and we can't wait for anything because we can't know what's semantically going on within the gatsby machinery right now.
Resolved the merge conflicts together with @sidharthachatterjee . Despite the age of the commit, luckily this file doesn't see many updates, so it's mostly about keeping @LekoArts's changes. Which I think we've done.