Make late runtime processor compatible with drush

After some more research, I came to conclusion that the kernel.terminate event might be a better fit, since its called in all contexts.

Patch attached executes the late runtime processor when the kernel is being terminate. No visible issues so far (except that the visitor gets to see the response faster :) ).

With the patch in #2 we were seeing successful invalidations not being deleted from the queue. Appears the deletion of successful invalidations was being done before the actual invalidation. Fixed it & commented the code accordingly.

This will be quite a surprise for Drush users. I dont think it is expected that when you run an innocent command like drush status that a purge can be issued. I recommend rolling this back.

Could you elaborate a little bit what kind of issues this can cause? A purge can be issued as well when visiting, for example, the status page through your browser. I'm having a hard time to see the difference?

The cli is different than the web server. It is used for scripting auto action tasks where no human is present. There is no way arbitrary purges should be happening in these operations imo.

I guess it depends on the task? If you have a script that changes content (or a migration even?), and you want to prevent visitors from seeing stale content, you might very well want to?

FWIW there are other modules doing pretty much the same, Search API being one of them (https://git.drupalcode.org/project/search_api/-/blob/8.x-1.x/src/Utility...).

Don't get me wrong though, I can see valid points for both sides.
In hindsight, maybe we should have made this configurable at the very least.

... the expectation IMHO is that a CLI execution should NOT trigger page-related events ...

As pointed at in my comment @ #3264141: [REGRESSION] Purge 8.x-3.1+ incompatible with Config Split, it's not the Purge module causing the KernelEvents::TERMINATE to be triggered, it's drush.

One thing I don't quite understand is why it was necessary to do this when the module purge_processor_cron already exists. If you want to purge through Drush, can't you just enable purge_processor_cron and schedule drush cron calls regularly?

They serve 2 completely different purposes. purge_processor_cron is interval based (every 15 minutes, for example). This ticket is about the late runtime processor, which is (nearly) instantaneous purging.

It seems like purge_processor_lateruntime was for web requests and purge_processor_cron was, indirectly, for the CLI via drush cron.

The code nor documentation has any indiciation that the purge_processor_lateruntime was only meant for "web"-like requests. This is just an assumption of someone you happen to agree with.

As already mentioned in #14, I see valid points for both sides. Nevertheless, you are pointing to an "issue" that is not specific to Purge. There are probably a myriad of modules, such as Search API, which are doing "web"-like things in the Kernel::TERMINATE event. If this is incorrect (it may very well be, I don't know), either the use of Kernel::TERMINATE in all those modules should then be only limited to non-CLI requests (eg. if (PHP_SAPI !== 'cli') { ... }) - and it should be documented somewhere - or the event shouldn't be triggered by drush at all (which is something you won't be able to tackle from this issue queue).