fix(dedupe): only count import locks held in the current database

[Maffooch]

Shortcut: sc-16686

Description

test_duplicate_of_a_test_just_reimported_is_deleted_once_the_import_has_ended (added in #16379) failed in 4 of the last 5 failed merge-queue runs, on amd64 and arm64, with Locations on and off. The flake comes from a real bug.

The excess-duplicate delete skips tests whose import lock is held. To find those tests, _import_lock_holders reads pg_locks. But pg_locks lists advisory locks for every database on the server, and an advisory lock only conflicts inside its own database. So a test was left out of the delete whenever a test with the same id was being imported in a different database:

• in CI, another --parallel worker, since each worker has its own test_defectdojo_N database;
• in production, another DefectDojo database on the same Postgres server. One instance's imports could hold back another instance's duplicate cleanup.

The per-chunk try-lock (tests_under_import_now) was already scoped to the database. Only the selection-time read and the abandoned-lock check used the unfiltered view.

I confirmed this on a scratch Postgres: with the lock held in db_a, the current holder query run from db_b reports the test as locked, while pg_try_advisory_xact_lock from db_b succeeds.

The fix filters the holder query to current_database().

Test results

New regression test test_import_lock_in_another_database_does_not_hold_back_the_delete holds the lock from the postgres database and checks that the duplicate is still deleted.

• Without the fix it fails: an import lock held in another database kept this database's excess duplicate.
• With the fix, all 50 tests in unittests.test_dedupe_delete_commit_race pass locally.
• ruff check (0.16.10) is clean.

Documentation

None needed.

🤖 Generated with Claude Code