draft content leaking into "live" server

We are also experiencing this issue.

In our case, we're not using storage entities. We are using content moderation with node entities.
Randomly, pages that are unpublished are leaking onto the live/build server.

Hoping there's going to be a resolution quickly for this one as our users can no longer rely on an "unpublished" page being unpublished.

I don't know if this solves your exact issue or not and it's difficult to test locally without having a separate preview/build server but this patch syncs up the logging service with the hooks, factors in the build_published option to early return for non-node entities when its true, and accounts for entities like "redirects" that don't have a publish state to also be triggered. It "should" resolve draft versions getting on build server. @lisagodare, your description involving referenced entities also in a moderated state may be a more unique issue and seemingly to me a case where those references might be better served as entity_reference_revisions if you're still having issues beyond this patch.

Noting here also... per Shane & Tyler at Gatsby, the version 2 of the module depends on fast_builds being enabled and thus it never sends json to the gatsby site like version 1 did. It just creates the log entity and triggers the gatsby site to make a request to the api endpoint to retrieve the data. So i've removed the json variables from the functions and the json logging setting should really just go away as its irrelevant since the data exists in the logging entity itself. One other important note, the "Only trigger builds for published content" is confusing as it really restricts updates to just nodes. The caveat of having this setting enabled means things not referenced to the node in an "entity reference" way like path aliases and redirects don't get triggered as part of node updates. I personally recommend disabling that setting.

Thanks for the updates @apmsooner. We will test this as a next step.

For the "Only trigger builds for published content" not being set, what would be a process to ensure live content isn't published or is it covered via Fastbuilds publish/preview payloads?

Patch works great!

This patch appears to work great for our needs.

We don't want to use Entity Reference Revisions fields, because we don't want to associate a specific revision of a related entity on the relating entity. This is because multiple different entities may relate to it, and we don't want them each showing a different revision. They should all show the same revision - either the default revision, if published, on the 'live' build; or the latest revision, published or not, on the 'preview' build.

Merging to dev.