Support sync kwarg in process_findings for inline post-processing by valentijnscholten · Pull Request #14309

Support sync kwarg in process_findings for inline post-processing by valentijnscholten · Pull Request #14309 · DefectDojo/django-DefectDojo

and others added 30 commits

December 29, 2025 17:13

…4 (.github/workflows/validate_docs_build.yml) (DefectDojo#13985)

Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>

…x/2.53.5-2.54.0-dev

Release: Merge back 2.53.5 into bugfix from: master-into-bugfix/2.53.5-2.54.0-dev

….53.5-2.54.0-dev

Release: Merge back 2.53.5 into dev from: master-into-dev/2.53.5-2.54.0-dev

…file.nginx-alpine) (DefectDojo#13995)

Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>

Updated weight for version 2.54.x and modified description.

…3.11 to v (dockerfile.integration-tests-debian) (DefectDojo#14003)

Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>

* dedupe reopen: add test cases that prove the bug

* remove obsolete method

* dedupe reopen: proceed with next candidate if candidate is mitigated

* rename methods

…Dojo#14017)

* added code to remove unwanted vulnerability ids

* Update dojo/finding/helper.py

---------

Co-authored-by: Cody Maffucci <46459665+Maffooch@users.noreply.github.com>

…thub/workflows/renovate.yaml) (DefectDojo#14025)

Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>

…efectDojo#14026)

Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>

…json) (DefectDojo#14023)

Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>

…ckerfile.integration-tests-debian) (DefectDojo#14008)

Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>

Add permission classes and refine queryset in BurpRawRequestResponseViewSet

* Add configuration permission check for authorized groups retrieval

* Add case where user has add_group, but not view_group

Thread the sync kwarg from process_findings through to dojo_dispatch_task
in both DefaultImporter and DefaultReImporter so callers can force
post_process_findings_batch to run inline instead of spawning additional
Celery tasks. Pop sync from kwargs in sync_process_findings to avoid
duplicate keyword argument errors.

The reimporter's process_results() checks kwargs.get("sync") to decide
whether to return real Finding objects or serialized JSON strings. Using
kwargs.pop() removed sync before process_results could see it, causing
findings_to_mitigate to contain JSON strings instead of Finding objects
and crashing close_old_findings with:
  AttributeError: 'str' object has no attribute 'refresh_from_db'

Switch from pop() to get() so sync remains in kwargs for process_results.

…akage

The sync=True injected by sync_process_findings was leaking through to
dojo_dispatch_task(post_process_findings_batch), forcing it to run
synchronously instead of async. This caused +7 to +61 extra queries in
performance tests.

- Remove sync=True from sync_process_findings (dead since ASYNC_FINDING_IMPORT removal)
- Remove sync kwarg threading in process_findings for both importers
- Remove dead serialization branches in process_results and process_findings
- Remove unused django.core.serializers imports

Maffooch marked this pull request as ready for review

February 13, 2026 20:01

valentijnscholten added a commit to valentijnscholten/django-DefectDojo that referenced this pull request

Feb 19, 2026

…s_results scaffolding

These three methods were introduced to support the ASYNC_FINDING_IMPORT feature
(async dispatch of findings processing to Celery). That feature has since been
removed, leaving a three-layer indirection:

  process_scan -> determine_process_method -> sync_process_findings -> process_findings
                                                                 -> process_results

None of this routing logic has any effect anymore:
- sync_process_findings just delegates to process_findings
- determine_process_method just delegates to sync_process_findings
- process_results just returns self.new_items / self.reactivated_items / etc.

Collapse the call chain so process_scan calls process_findings directly and
process_findings returns the finding lists directly. This also fixes the
indirection that was the root cause of DefectDojo#14309's performance test failures.

Maffooch pushed a commit that referenced this pull request

Feb 23, 2026

…s_results scaffolding (#14351)

These three methods were introduced to support the ASYNC_FINDING_IMPORT feature
(async dispatch of findings processing to Celery). That feature has since been
removed, leaving a three-layer indirection:

  process_scan -> determine_process_method -> sync_process_findings -> process_findings
                                                                 -> process_results

None of this routing logic has any effect anymore:
- sync_process_findings just delegates to process_findings
- determine_process_method just delegates to sync_process_findings
- process_results just returns self.new_items / self.reactivated_items / etc.

Collapse the call chain so process_scan calls process_findings directly and
process_findings returns the finding lists directly. This also fixes the
indirection that was the root cause of #14309's performance test failures.