Closed janosh closed 2 years ago
Haroenv
commented
5 years ago there seem to be two things, the maximum time exceeded, as well as an id of undefined. I don't exactly recognise both of those, but can you try to see which code in Gatsby throws that error?
janosh
commented
5 years ago The line that throws the error is
state.delete(action.payload.id);in gatsby/dist/redux/reducers/nodes.js
"use strict";
module.exports = (state = new Map(), action) => {
switch (action.type) {
case `DELETE_CACHE`:
return new Map();
case `CREATE_NODE`:
{
state.set(action.payload.id, action.payload);
return state;
}
case `ADD_FIELD_TO_NODE`:
case `ADD_CHILD_NODE_TO_PARENT_NODE`:
state.set(action.payload.id, action.payload);
return state;
case `DELETE_NODE`:
{
state.delete(action.payload.id);
return state;
}
case `DELETE_NODES`:
{
action.payload.forEach(id => state.delete(id));
return state;
}
default:
return state;
}
};
//# sourceMappingURL=nodes.js.mapSomehow gatsby-plugin-algolia seems to be creating actions of type DELETE_NODE without a payload.
Haroenv
commented
5 years ago That's really odd, since the plugin doesn't even create nodes, it only queries the graphql 🤔 I think the error is unrelated
janosh
commented
5 years ago Could it be gatsby-plugin-algolia conflicting with another package? Because these types of errors only started occuring after I started using it and netlify build always fails during Algolia: query [n]: moving copied index to main index.
Haroenv
commented
5 years ago that would seem quite unlikely. What are the other plugins you're using?
janosh
commented
5 years ago Another possibility just occured to me. One difference between my local gatsby builds and those running on netlify is that locally there's at most one build going on at a time.
If I immediately merge a pull request in one of my repos, however, netlify builds the deploy preview and the master branch simultaneously. Could it be that both processes trying to access my Algolia indices simultaneously is causing this problem?
Haroenv
commented
5 years ago That is possibly a source of a bug (you should probably give staging a separate index name), but it would surprise me if that throws an error like the one described, since that code isn't used in the plugin
kuworking
commented
5 years ago I'm seeing the same error, even though in my case it doesn't stop the compilation (in run develop, haven't tried build yet)
So in my case this error has to be unrelated to an "id" property of (in this case) my module.
*Ah, and I cannot see any consecuence of this error in the site
kuworking
commented
5 years ago For me, the error appears when this code is included. So if I eliminate the lines marked with >>>>> I don't see the error with the "id" property (code located in gatsby-node.esm.js)
exports.onCreatePage = ({ page, actions }) => {
const { createPage, deletePage } = actions
const oldPage = Object.assign({}, page)
if (page.path !== `/`) page.path = page.path.replace(/\/$/, ``)
if (/^.\d{4}\.\d{2}\.\d{2}\./.test(page.path)) page.path = '/' + page.path.split('.').pop()
>>>>> if (page.path !== oldPage.path) {
>>>>> deletePage(oldPage)
>>>>> createPage(page)
>>>>> }
}Since this is not related to the plugin, I've submitted a question in gatsby
richhiggins
commented
4 years ago I'm seeing this too, and inconsistently too. for me it hangs like this -
never gets past that, I have to cancel and trigger a new deploy which may or may not have a different outcome 😕
janosh
commented
4 years ago @richhiggins For me the issue was definitely due to concurrent builds attempting to access or write to the same resources. It completely disappeared once I disabled netlify builds for feature branches and PRs, i.e. with changes to master the only thing that triggers a build. Have you checked whether that may be the case for you as well?
richhiggins
commented
4 years ago interesting... I wonder if in my case it's because I have 2 queries which the plugin appears to process asynchronously and they are accessing the same index.
dreamer01
commented
4 years ago I am still facing the same issue, my build is stuck/freeze at Algolia Query Indexing and copying.
Has anybody found any solution or workaround for this?
dreamer01
commented
4 years ago I am still facing the same issue, my build is stuck/freeze at Algolia Query Indexing and copying.
Has anybody found any solution or workaround for this?
The workaround I found is to clear your indexes from Algolia and then run the build.
richhiggins
commented
4 years ago I seem to have solved this by refactoring to a single algolia query. we also experience the issue on another project, my current theory there is the _tmp index is being written to concurrently causing issues. planning to rename that temp index with a time stamp to test that theory out
dreamer01
commented
4 years ago I seem to have solved this by refactoring to a single algolia query.
You can refractor it to single query but how were you able to resolve it to multiple indexes, as query options include indexName also
If could help me with this here is how I am using my queries
const queries = [
{
query: resourceQuery,
transformer: ({ data }) => data.gcms.resources.map(resource => resource),
indexName: `resource`,
},
{
query: blogQuery,
transformer: ({ data }) => {
return data.gcms.blogs.map(blog => blog)
},
indexName: `blog`,
},
]
prichey
commented
4 years ago I'm seeing this as well, has anyone figured out a reliable solution?
Haroenv
commented
4 years ago If you fork the plugin and comment out the element where it actually saves objects to Algolia, does it still freeze? Does someone have an open source example which fails?
Haroenv
commented
2 years ago I can't see this being reproduced anymore. If you have this again, please open a new issue with reproduction, thanks!
Since adding
gatsby-plugin-algoliato some of my projects, they have been suffering from freezing builds on netlify. The build logs below show that the failing step isThis happens on every 4th or 5th deploy, I'd say. Interestingly, so far this has never happened when building locally. So it's very likely related to netlify in some way.
@Haroenv Can you tell from the logs what exactly could be causing this issue and how we might fix it?