Follow-up to #176, found while checking prod after the deploy.
What the first fix missed
#176's migration cleared rows whose legacydate_taken_source was filename. The true-instant drain (#118) only writes the new-contract triple, though. So a row could have a correct legacy date from exiftool and still carry the old filename matcher's impossible year in date_utc. Prod has three, all in Phone Backup:
file
legacy (exiftool, correct)
date_utc (bad)
container CreateDate
2016/07/VID_20950505_044049.mp4
2016-07-15
2095-05-05
2016-07-14 23:49
2017/07/VID_22290524_080551_818.mp4
2017-07-14
2229-05-24
2017-07-14 17:58
2017/11/VID_185800302_235056_842.mp4
2017-11-18
8580-03-03
—
Fix
Migration 2026-10-17-000000_reresolve_implausible_utc_dates clears only date_utc, camera_offset_minutes and date_taken_tz_source wherever date_utc is outside [1995-01-01, 2028-01-01) UTC, whatever the source. date_utc IS NULL puts those rows back in backfill_utc_dates, which re-resolves them with the gated matcher (they'll pick up their container dates). The frozen legacy pair isn't touched. On prod, these three are the only rows with date_utc out of range, so nothing else gets re-processed.
Tests
New: migration_clears_implausible_true_instants_but_keeps_legacy_dates seeds the prod shape, then checks that the triple is cleared, the legacy date is kept, and a normal row is untouched. It shares a conn_before_migration helper with the first migration's test.
Full suite: 746 lib + 838 bin pass; clippy is clean.
After deploy
SELECT COUNT(*) FROM image_exif WHERE date_utc < 788918400 OR date_utc >= 1830297600 should return 0 once the drain has run.
Follow-up to #176, found while checking prod after the deploy.
## What the first fix missed
#176's migration cleared rows whose **legacy** `date_taken_source` was `filename`. The true-instant drain (#118) only writes the new-contract triple, though. So a row could have a correct legacy date from exiftool and still carry the old filename matcher's impossible year in `date_utc`. Prod has three, all in Phone Backup:
| file | legacy (exiftool, correct) | date_utc (bad) | container `CreateDate` |
|---|---|---|---|
| `2016/07/VID_20950505_044049.mp4` | 2016-07-15 | 2095-05-05 | 2016-07-14 23:49 |
| `2017/07/VID_22290524_080551_818.mp4` | 2017-07-14 | 2229-05-24 | 2017-07-14 17:58 |
| `2017/11/VID_185800302_235056_842.mp4` | 2017-11-18 | 8580-03-03 | — |
## Fix
Migration `2026-10-17-000000_reresolve_implausible_utc_dates` clears only `date_utc`, `camera_offset_minutes` and `date_taken_tz_source` wherever `date_utc` is outside [1995-01-01, 2028-01-01) UTC, whatever the source. `date_utc IS NULL` puts those rows back in `backfill_utc_dates`, which re-resolves them with the gated matcher (they'll pick up their container dates). The frozen legacy pair isn't touched. On prod, these three are the only rows with `date_utc` out of range, so nothing else gets re-processed.
## Tests
- New: `migration_clears_implausible_true_instants_but_keeps_legacy_dates` seeds the prod shape, then checks that the triple is cleared, the legacy date is kept, and a normal row is untouched. It shares a `conn_before_migration` helper with the first migration's test.
- Full suite: 746 lib + 838 bin pass; clippy is clean.
## After deploy
`SELECT COUNT(*) FROM image_exif WHERE date_utc < 788918400 OR date_utc >= 1830297600` should return 0 once the drain has run.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
The first #160 migration cleared rows whose legacy date_taken_source
was 'filename'. But the true-instant drain wrote only the new-contract
triple, so rows with a correct legacy date (e.g. an exiftool container
date) could still carry a filename-derived implausible year in
date_utc. Prod has three: VID_<counter> videos dated 2095 / 2229 / 8580
whose containers say 2016 / 2017.
Clear just the triple wherever date_utc is outside [1995, 2028) UTC;
backfill_utc_dates re-resolves it with the gated matcher, and the
frozen legacy pair is left alone. On prod those three are the only
rows with date_utc out of range.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
cameron
merged commit d959fc77cf into master2026-10-17 03:50:06 +00:00
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Follow-up to #176, found while checking prod after the deploy.
What the first fix missed
#176's migration cleared rows whose legacy
date_taken_sourcewasfilename. The true-instant drain (#118) only writes the new-contract triple, though. So a row could have a correct legacy date from exiftool and still carry the old filename matcher's impossible year indate_utc. Prod has three, all in Phone Backup:CreateDate2016/07/VID_20950505_044049.mp42017/07/VID_22290524_080551_818.mp42017/11/VID_185800302_235056_842.mp4Fix
Migration
2026-10-17-000000_reresolve_implausible_utc_datesclears onlydate_utc,camera_offset_minutesanddate_taken_tz_sourcewhereverdate_utcis outside [1995-01-01, 2028-01-01) UTC, whatever the source.date_utc IS NULLputs those rows back inbackfill_utc_dates, which re-resolves them with the gated matcher (they'll pick up their container dates). The frozen legacy pair isn't touched. On prod, these three are the only rows withdate_utcout of range, so nothing else gets re-processed.Tests
migration_clears_implausible_true_instants_but_keeps_legacy_datesseeds the prod shape, then checks that the triple is cleared, the legacy date is kept, and a normal row is untouched. It shares aconn_before_migrationhelper with the first migration's test.After deploy
SELECT COUNT(*) FROM image_exif WHERE date_utc < 788918400 OR date_utc >= 1830297600should return 0 once the drain has run.🤖 Generated with Claude Code