Alternative event for the previous beforeProcessFeed behaviour

[jamesmacwhite]

Description

Since the introduction of batched jobs and amending the beforeProcessFeed event in 6.9.0 to work with per page batches rather than run once for the entire feed #1619. This means there is now no reliable Feed Me event that only run once before a feed is processed.

While this is a bit of a bespoke scenario, I have code that was using beforeProcessFeed to acquire a mutex during a Feed Me processing called "FEED_ME_PROCESSING" in an effort to stop Scout IndexElement queue jobs being raised because of this issue: studioespresso/craft-scout#180, it stems from the fact that Scout will raise a large amount of IndexElement jobs per element during a Feed Me import. The proper fix is Scout to leverage the newer BULK_OPTs events alongside the Feed Me batched jobs, but for now, this isn't implemented.

While we could turn off the scout sync setting during Feed Me imports this would technically block general Craft CMS entry save events, which we wouldn't want, which is why we went down the Feed Me event and mutex route. However, there isn't a reliable event to use to acquire a mutex once and release it at the end. Instead an acquire mutex would be run multiple times.

Potentially, it would be good if an event could be implemented that provides the original behaviour of beforeFetchFeed but named something else. I understand that beforeProcessFeed needed to change to make sense related to batching, but the original behaviour was also potentially relied on as well.

[linear]

PT-2876 Alternative event for the previous beforeFetchFeed behaviour

[jamesmacwhite]

An alternative approach I've looked at without using a mutex is preventing Scout's queue jobs from being raised by detecting if the request is a console request, then running some Queue event behaviour conditionally on the getIsConsoleReqest() method, which stops indexing jobs from being raised during Feed Me imports but allows the Craft CMS entry save events to continue to work.

I'll leave the original request as something to consider for behaviour pre-batch jobs if something like beforeStartFeed is viable as a single time triggered event.