\Drupal\strata\Hook CronCapture

Drives everything that has no request to run in.

Cron is what makes capture into a backup on a site nobody is watching. A busy site also flushes from the request that filled the window, but a quiet one may go hours between writes, and the age bound exists precisely so those few writes still reach the store.

Four things run here, in this order and for these reasons:

1. Code capture, because a deploy is not an event Drupal dispatches. It runs FIRST so the operations it appends are sealed by the flush in the same run rather than waiting for the next.
2. The reconciler, which detects tables that changed with nothing capturing them and appends the rows to close the gap - again before the flush, so those rows are sealed too.
3. The flush, sealing whatever the window now holds.
4. Keyspace discovery, which writes no operations and only describes what is there, so it runs last and cannot delay anything that does.
5. Dictionary training, on its own long interval. It reads segments back and compresses the samples several times to score the candidates, which is far too slow to run every cron and pointless to run often: a dictionary describes the shape of what a realm writes, and that shape changes over weeks rather than minutes.
6. Anomaly detection, which takes one reading of the store and scores it against the site's own earlier readings. It runs after the flush so the reading includes what this cron just sealed rather than describing the state before it.
7. A restore drill, on its own interval and off by default. It replays a sample of subjects and compares them against what the site holds, which costs a replay per subject - the one stage here whose cost scales with the size of the sample rather than with what changed.
8. Telemetry export, last, because it reports what every earlier stage did and an export that ran first would describe the previous run.

No stage can stop cron. A cron hook that throws stops every later hook in the queue, so a storage outage would take the site's search indexing and cache warming down with it. Each stage is caught separately, so one failing does not skip the others either.

The engine arrives rather than the eight things it builds, and that is load bearing. Every stage is assembled from configuration and assembling one can refuse: encryption is on by default with no key, so Engine::flusher() throws on a site nobody has configured yet. Drupal resolves a cron hook's service inside ModuleHandler::invokeAllWith(), which runs before the per-module try/catch in Cron::invokeCronHandlers() and before this class can check anything. Taking the stages as constructor arguments therefore skipped every module's cron and left the cron lock held for its full 900 seconds. Each stage resolves what it needs inside its own guard instead.

Constant

Properties

Methods