-
released this
2026-05-26 18:06:40 -04:00 | 578 commits to dev since this releaseThird hotfix for v26.05.26.1's alembic 0022 migration. PR #26 → main, merge commit
52fff00, pinned headf3e8f30verified.What still broke after v26.05.26.3
IntegrityError: duplicate key (image_record_id, post_id)=(82045, 5411) already exists [parameters: {'keep': 5411, 'drop_': 14147}]When the same image legitimately had
ImageProvenancerows under BOTH a keep Post (5411) and a drop Post (14147) — e.g. the same image attached to two different gallery-dl posts that we're now merging — theUPDATE image_provenance SET post_id = keep WHERE post_id = dropwould try to plant a second (image, keep) row, trippinguq_image_provenance_image_postfrom alembic 0021. The after-the-fact dedupe-DELETE never ran because the UPDATE fires UNIQUE row-by-row.Fix
Pre-DELETE
image_provenancerows under the drop Post whoseimage_record_idalready has a provenance under the keep Post (those rows are redundant — the keep-side row already represents that image-to-post link). Then the remaining drop-side provenance rows get UPDATEd safely with no collisions possible.This now handles all three collision patterns the migration has hit:
- Two Posts under same/different sources sharing
external_post_id, canonical has it → handled by v26.05.26.2's pre-merge case A - Two non-canonical Posts sharing
external_post_id, canonical doesn't → handled by v26.05.26.3's full-group pre-merge - Image already has provenance under both keep and drop → handled by THIS pre-DELETE
Deploy
Pull
:latest, force-update services. Alembic 0022 should apply cleanly.If it errors again, paste the new traceback — there may be yet another pattern in the migration's nested foreign-key web that needs the same row-by-row treatment.
Downloads
- Two Posts under same/different sources sharing