New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat(gatsby-core-utils): add fetch mutex for PQR #33161
Conversation
| if (entry.status === `complete`) { | ||
| cb(entry.result) | ||
| } else { | ||
| setTimeout(() => { | ||
| pollUntilComplete(cache, url, buildId, cb) | ||
| // Magic number | ||
| }, 500) | ||
| } |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What happens if a worker starts polling but then the "main" worker fails (i.e. requestRemoteNode throws)? I don't see how it can exist from this function in this case. Can we have a test case for it as it is a typical scenario?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We keep on hanging
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Depends on how folks use it. If it happens in custom resolver - the corresponding field can just return null (graphql allows partial errors for nullable fields)


Description
When multiple workers fetch the same file we end up with multiple requests to that file. We write to a seperate tmp file but the end result writes (fs.move) to the same file.
This can lead to corrupt files if other parts of the application are resolving it. This PR creates some hacky mutex implementation to make it only write once. It's still possible to write multiple tmp files.
As an adittion I took the inFlight cache from #30391 and implemented it as well to do less polling.