• bvandeusen released this 2026-05-26 18:06:40 -04:00 | 578 commits to dev since this release

    Third hotfix for v26.05.26.1's alembic 0022 migration. PR #26 → main, merge commit 52fff00, pinned head f3e8f30 verified.

    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 ImageProvenance rows 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 — the UPDATE image_provenance SET post_id = keep WHERE post_id = drop would try to plant a second (image, keep) row, tripping uq_image_provenance_image_post from alembic 0021. The after-the-fact dedupe-DELETE never ran because the UPDATE fires UNIQUE row-by-row.

    Fix

    Pre-DELETE image_provenance rows under the drop Post whose image_record_id already 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:

    1. Two Posts under same/different sources sharing external_post_id, canonical has it → handled by v26.05.26.2's pre-merge case A
    2. Two non-canonical Posts sharing external_post_id, canonical doesn't → handled by v26.05.26.3's full-group pre-merge
    3. 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