PhoenixKit.Modules.Storage.Jobs.CaptureDateBackfill (phoenix_kit v2.52.2)

Copy Markdown View Source

The capture-date backfill as a job run (storage.capture_date_backfill): dates the images and videos stored before capture dates existed (V200), a batch at a time, in uuid order, so an admin sees how far it is and can pause or cancel it on Admin → Jobs.

The work is PhoenixKit.Modules.Storage.Workers.CaptureDateBackfillJob's (run_batch/2 there is what every batch calls); this is the shape the Jobs engine drives. It is the first kind built on the engine and the simplest: a site-wide pass with a cursor. Replaying a batch is safe — a file that already has a date is not a candidate any more, and the write itself is guarded.

Counts after a crash are approximate. The pass selects files that still have no date, so a batch that dies after dating some files and before its checkpoint leaves those files correctly dated but counted by no one — the replay never sees them. The run still completes; its done (and, when it was the first batch, total) can be lower than the number of files that ended up dated.

restart/0 is :merge: a second trigger while a pass runs changes nothing (the files it would date are dated by the running pass, or by the next one).