@iFlameing So, please, use this week to review how the existing source plugins have been tested.
Only then we should really decide, what kind of testing makes sense here.
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