reimport-scan with close_old_findings_product_scope=true fails to mitigate findings in other engagements

[dn281090pdi]

Description
There is an issue with the cross-engagement mitigation logic during a reimport-scan. Even when close_old_findings_product_scope is set to true, findings that exist in a "Interactive" engagement are not automatically mitigated when a subsequent "CI/CD" engagement (within the same Product and Service scope) reports a clean scan (vulnerability fixed).

Environment
DefectDojo Version: 2.54.0
Deduplication Settings:
Deduplicate findings: Active (Global)
Delete duplicates: Active
Deduplication within this engagement only: Inactive (at engagement level)
Deployment method: Kubernetes
Scan type: Sonatype
Reimport params: --form close_old_findings=true --form close_old_findings_product_scope=true --form deduplication_on_engagement=false
T

report_sona.json

test title the same in import and reimport

Steps to Reproduce
Create a Product with two different engagements:
Engagement 1: "Interactive" type.
Engagement 2: "CI/CD" type.

1: Perform a scan and upload the report to Engagement 1 using /api/v2/import-scan/. (Finding X is created and active).
2: Fix the vulnerability in the source code.
3: Perform a new scan and upload the result to Engagement 2 using /api/v2/reimport-scan/ with the following parameters:

test_title: "SCA" (Identical to Engagement 1)
service: "1" (Identical to Engagement 1)
close_old_findings: true
close_old_findings_product_scope: true

Actual Behavior
Finding X remains Active in Engagement 1. The system does not recognize the fix across engagement boundaries.

Expected Behavior
Since close_old_findings_product_scope is true and the service and test_title match, Finding X in Engagement 1 should be automatically mitigated because it is no longer present in the latest scan.

ps didn't reproduce with trivy

report_sona.json

[valentijnscholten]

By design reimport only closes findings inside the same Test: https://docs.defectdojo.com/en/open_source/archived_docs/usage/features/#deduplication---apiv2-parameters
And from the API spec:

[dn281090pdi]

Thank you for the clarification regarding the documentation.
We have observed that Trivy successfully mitigates findings across different engagements via reimport-scan (the same scenario), which seems to deviate from the 'same test' rule.

[valentijnscholten]

Looking at the code this is not possible, but I am open to a full bug report with steps to reproduce or full proof via DEBUG logs. The two screenshots above show only 1 finding so I am missing the proof of the mentioned behaviour. The screenshot seems to suggest an import was run which closed it, otherwise it would mention reimport in the second screenshot.