Flaky test: test_dedupe_delete_commit_race.test_duplicate_of_a_test_just_reimported_is_deleted_once_the_import_has_ended intermittently fails in the merge queue #16396

Summary

unittests.test_dedupe_delete_commit_race.TestDupeDeleteRacesInFlightWriter.test_duplicate_of_a_test_just_reimported_is_deleted_once_the_import_has_ended fails intermittently in merge_group (merge-queue) runs, independent of the PR being queued. Because it fails inside the queue, it dequeues otherwise-green PRs with a generic CI_FAILURE.

Failure

FAIL: test_duplicate_of_a_test_just_reimported_is_deleted_once_the_import_has_ended
AssertionError: True is not false : an excess duplicate of a test with no import running
was kept because the test was reimported recently
  File "unittests/test_dedupe_delete_commit_race.py", line 824, in
    test_duplicate_of_a_test_just_reimported_is_deleted_once_the_import_has_ended
    self.assertFalse(Finding.objects.filter(id=matched.id).exists(), ...)

The test backdates both findings (updated ~120 min ago, past the grace window), sets the parent Test.updated = now to simulate "a reimport finished just now", runs _async_dupe_delete_impl(), and asserts the excess duplicate is deleted — i.e. recent test reimport activity alone must not hold deletion back. Intermittently the duplicate is kept, so the assertion fails.

Evidence it is environment/timing-dependent, not PR-specific

The identical failure (same test, same assertion) occurs across completely unrelated PRs' merge-queue batches:

• merge_group run 39047666815 — batch for a backend task-scheduling change.
• merge_group run 38988032441 — batch for a docs-only PR (docs(tables): a page's pinned context shows as a locked chip ahead of the connective #16390), which cannot affect dedupe behavior at all.

Both ran the full suite (~8180–8189 tests) and failed only on this one test. The same test passes on the same commits' pre-queue PR checks and in other queue batches, which is the signature of a flaky test rather than a real regression.

Likely area

The grace-period / skip-tests-under-import logic added in #16379 (DUPE_DELETE_GRACE_MINUTES, DUPE_DELETE_SKIP_TESTS_UNDER_IMPORT, DUPE_DELETE_ABANDONED_IMPORT_LOCK_MINUTES) in _async_dupe_delete_impl. The assertion message points at the "reimported recently" path: under full-suite load the control case intermittently treats the test as still-under-import (or otherwise within a time window) and skips the duplicate. Candidate causes: a wall-clock/timezone.now() boundary that is not frozen in the test, or a PostgreSQL advisory-lock / state check that is sensitive to concurrent connections in the full parallel run.

Suggested fix

Make the control case deterministic — freeze/mkock timezone.now() across setup and the delete call so the grace/recency window cannot be crossed by wall-clock drift, and ensure the test's advisory-lock/pg_locks view of "under import" is isolated from concurrently running tests. Owners of #16379 are best placed to pin the exact mechanism.

Impact

Non-deterministic merge-queue failures that dequeue unrelated, fully-green PRs and force manual re-queueing.