I'm sorry that I'm online weird hours now in July. I'm actually on vacation and I'm mostly on keyboard when the rest of my family is already asleep.
That’s absolutely fine :)
I'm once again working on top-level acceptance tests for your work and I'm seeing those random errors that might actually be GatsbyJS issues. I haven't properly reproduced those yet.
Those might also be issues caused by gatsby-source-plone asynchronously processing multiple conflicting notifications.
I wonder if we should wrap notification handlers with a lock https://www.npmjs.com/package/async-lock
@iFlameing Ok. I believe the README of https://www.npmjs.com/package/async-lock explains it well.
@iFlameing I believe that currently every "await" within a single handling of ws.onmessage allows NodeJS to switch execution context.
For example, whenever we are waiting for the results of call to search-endpoint (for example, to update breadcrumbs or navigation), NodeJS is allowed to start processing next ws.onmessage event.
I have now added some acceptance tests that do "black box testing" that your GSOC additions update gatsby develop when pages are deleted, modified or added.
Example run starting from line 1222 at output log of https://travis-ci.org/collective/gatsby-source-plone/jobs/561341455
I cannot say, into how small functions you should refactor the code. Something that looks clean and easily understandable. Something you could be proud to say you wrote it.
After refactoring and updating the documentation (probably the MD-files in docs-folder is enough; updating the Plone site fixture requires use of Plone), it's up to you if you'd like to do some stretch goals (websocket reconnection, logging refactoring, or more) or just try