fix(finding): retry deferred-FK race on single-finding delete

[Maffooch]

Description

Deleting a single finding via the API (DELETE /api/v2/findings/{id}/) or the UI delete view intermittently returns an Internal Server Error under load, with:

DETAIL: Key (id)=(<finding_id>) is still referenced from table "dojo_test_import_finding_action".

raised at transaction COMMIT time.

Root cause is a delete-vs-import race. A single-finding delete runs Django's collector, which clears the finding's Test_Import_Finding_Action children before deleting the finding row. Those FK constraints are DEFERRABLE INITIALLY DEFERRED, so a concurrent import that commits a new child row referencing the finding between the child clear and the transaction COMMIT trips a foreign-key violation (SQLSTATE 23503) at commit time. The reference is real but transient: on a re-run the collector clears the newly-created child and the delete completes.

The async cascade delete already handles exactly this race (_is_retryable_delete_conflict in dojo/utils.py, retrying on FK-violation 23503 and on deadlock/serialization 40P01/40001). The synchronous single-finding delete path had no such protection.

This PR adds delete_finding_with_conflict_retry(finding, **kwargs) in dojo/finding/helper.py, which re-runs Finding.delete() on a transient conflict with exponential backoff and re-raises anything else (e.g. a unique-violation 23505) or a conflict that survives every attempt. Each attempt runs in a fresh transaction (there is no ATOMIC_REQUESTS), and the failed attempt has already rolled back, so the finding still exists to be re-deleted. It is wired into both the API viewset (dojo/finding/api/views.py) and the UI delete view (dojo/finding/ui/views.py).

No behavior change on the happy path; no schema/model change, so no migration.

Test results

Added unittests/test_finding_delete_conflict_retry.py (mocks Finding.delete, so no DB needed), covering:

• success on first attempt deletes once, no sleep;
• FK-conflict (23503) retried, then succeeds;
• deadlock / serialization-failure (40P01 / 40001) retried, then succeeds;
• unique-violation (23505) is not retried and surfaces immediately;
• a conflict that survives every attempt is re-raised;
• retry backoff grows with each attempt.

The SQLSTATE detection and retry control-flow were also validated against real psycopg.errors exception shapes.

Documentation

None needed — internal reliability fix, no user-facing behavior or settings change.

Checklist

• Bugfix submitted against the bugfix branch.
• Ruff compliant.
• Added unit tests.
• No model changes / no migration required.

🤖 Generated with Claude Code

---

Generated by Claude Code