[Maffooch]

Description

Documents the web-request statement bound that ships in DefectDojo Pro 3.5.0, on the on-prem hardware sizing page next to the uWSGI harakiri settings.

A harakiri restart stops the web process but not the PostgreSQL query it was running, which keeps going until it finishes. From 3.5.0, PostgreSQL itself stops any single statement of a web request that runs 30 seconds longer than that service's harakiri allows, and the request answers with a 503. The new section explains the default per service, the three settings that change it (DD_DATABASE_WEB_STATEMENT_TIMEOUT, DD_DATABASE_IMPORT_STATEMENT_TIMEOUT, DD_DATABASE_WEB_LONG_STATEMENT_TIMEOUT), that imports and exports may get a higher bound but never past their own service's harakiri, that background tasks, migrations and management commands are never limited, what changes behind a connection pooler such as PgBouncer, and how to change it on Kubernetes (config.extra or django.extraEnv, which reaches the web and import pools alike).

Docs only; no code change.

🤖 Generated with Claude Code

[Maffooch]

Adversarial review (full tier, Opus)

Reviewed together with the application change this page documents. Docs only, so the pass checked each sentence and each table row against the shipped code and deployment files on the dev line.

Checked and accurate

• The two Compose service names (dojo, dojo-import-scan) match the shipped Compose bundles.
• The defaults on Compose: the web service's harakiri is 900 and the import service's is 1770, so the bounds are 870 s and 1740 s, 30 s under each.
• Background tasks, migrations and management commands get no bound. The bound is set only in uWSGI (web) processes, chosen from the process command line.
• The 503 and its message. The import-path gap in the application change (see its review) affects how true "the request answers with a 503" is for imports.

Break attempts on the text

1. The Kubernetes paragraph against the chart. The import deployment reads the same ConfigMap (envFrom) and the same django extra env as the web deployment. So a value set "through the chart's extra environment" also bounds the import pool. The chart also has no per-pool import setting: DD_DATABASE_IMPORT_STATEMENT_TIMEOUT is a Compose-only remap. The page does not say either of these things.
2. A chart with the import pool disabled. The chart then gives the web pool the import pool's harakiri (1770), so the web bound is 1740 s, not the 870 s the page states for dojo.
3. DD_UWSGI_HARAKIRI=0 (harakiri off). The code falls back to 1770, so the bound is 1740 s. The page says the default is "30 seconds under DD_UWSGI_HARAKIRI", which reads as no bound when harakiri is off.
4. "Imports and exports get 1740 seconds on either service." On dojo, uWSGI harakiri still ends the request at 900 s. An export there can never run 1740 s; only its database statement can outlive the request by that long. The application review asks for this bound to be capped at the service's own bound. Whatever that change settles on, this sentence has to describe it.
5. A database behind a connection pooler. The bound is sent as a libpq options startup parameter. PgBouncer refuses unknown startup parameters unless it is configured to ignore them, and I have not verified how managed poolers behave. Nothing on the page tells an operator with a pooler that this changes in 3.5.0 or that 0 turns it off.

Findings

• R1 suggestion this-pr docs/content/get_started/pro/onprem/hardware_sizing.md:113: the Kubernetes sentence needs three facts. The setting is made through config.extra (or django.extraEnv). A value set there applies to the web and import pools alike, because the chart has no per-pool import setting. With django.uwsgiImport.enabled: false the web pool's bound is 1740 s, not 870 s.
• R2 suggestion this-pr docs/content/get_started/pro/onprem/hardware_sizing.md:110: mark DD_DATABASE_IMPORT_STATEMENT_TIMEOUT as Compose only in the table, since the chart has no such setting.
• R3 suggestion this-pr docs/content/get_started/pro/onprem/hardware_sizing.md:105: add one sentence for installs that reach PostgreSQL through PgBouncer or another connection pooler. The bound travels as a connection startup parameter, a pooler may refuse it, and DD_DATABASE_WEB_STATEMENT_TIMEOUT=0 turns it off.
• R4 nit this-pr docs/content/get_started/pro/onprem/hardware_sizing.md:109: the default column should say that harakiri unset or 0 gives 1740 s.
• R5 nit this-pr docs/content/get_started/pro/onprem/hardware_sizing.md:105: correct the imports-and-exports sentence after the long-bound change in the application PR. That bound is capped by each service's harakiri, so an export on dojo cannot run 1740 s.

Recommendation

Changes required: 5 open (3 suggestions, 2 nits), all on this PR.

Not checked: the rendered page on the docs site.

[Maffooch]

Resolution of the adversarial review

All five findings are fixed in a3db692.

• R1 fixed in a3db692: the Kubernetes paragraph now names config.extra / django.extraEnv. It says a value set there applies to the web and import pools alike, and that with django.uwsgiImport.enabled: false the web pool's limit is 1740 seconds.
• R2 fixed in a3db692: the table row for DD_DATABASE_IMPORT_STATEMENT_TIMEOUT now starts with "Docker Compose only."
• R3 fixed in a3db692: a new paragraph says the limit is a connection startup option, a pooler such as PgBouncer may refuse it or drop it, and the settings should be 0 there.
• R4 fixed in a3db692: the default column gives 1740 when harakiri is unset or 0, and the prose says so too.
• R5 fixed in a3db692: the imports-and-exports sentence now matches the application change. Their limit is never more than 30 seconds under their own service's harakiri, so with the defaults they get the same limit as everything else on that service. The DD_DATABASE_WEB_LONG_STATEMENT_TIMEOUT row says a higher value is capped and 0 means the default.

[Maffooch]

Adversarial review: second pass on the fixes (full tier, Opus)

Docs only. This pass checks the resolutions of the first verdict at a3db692, reading every sentence and table row against the application change as it now stands, the shipped Compose files and the Helm chart. It was run by a session that wrote neither the page nor the first verdict.

CI: every check that ran is green. The skipped jobs were skipped because the diff is docs only.

Re-check of the first verdict

• R1 is fixed. The Kubernetes paragraph names config.extra and django.extraEnv. It says a value set there reaches both pools, which is right: the import deployment reads the same ConfigMap through envFrom and the same django extra env. It also gives 1740 seconds on the web pool when django.uwsgiImport.enabled is false, which matches the chart: that pool then takes the import pool's harakiri of 1770.
• R2 is fixed. The DD_DATABASE_IMPORT_STATEMENT_TIMEOUT row starts "Docker Compose only." The chart has no such setting.
• R3 is fixed. The new paragraph covers the connection startup option, PgBouncer or another pooler refusing it or dropping it, and setting the limits to 0.
• R4 is fixed. The prose and the two per-service rows say 1740 when harakiri is unset or 0. That matches the code: harakiri unset or 0 falls back to 1770, and 1770 minus 30 is 1740.
• R5 is fixed. The imports-and-exports sentence now matches the application change: the long limit is capped at 30 seconds under the service's own harakiri, so with the defaults it equals the normal limit. The long-timeout row says that a higher value is capped and that 0 means the default. Both checked against the code: 5000 on a 900-second service gives 870, and unset or 0 gives the ceiling.

Break attempts on the new text

1. Harakiri 0 on the import service: the page says 1740, and the code gives 1740. Correct.
2. Helm with the import pool disabled and either harakiri set to 0: the chart then sets the web pool's harakiri to 0, which falls back to 1740. The page's "1740 when that is unset or 0" covers that case. Correct.
3. Background tasks, migrations and management commands: a probe of each process role (Celery worker and beat, migrate, initialize, shell, an orchestration worker) shows no limit applied. Only the web server role gets one. Correct.
4. The DD_DATABASE_WEB_LONG_STATEMENT_TIMEOUT row's Default column says "30 seconds under the service's harakiri", but the two rows above it also give the 1740 fallback. The code applies the same fallback to the long limit: with harakiri 0 it is 1740. This one row is inconsistent with the others (R1).

Findings

• R1 nit this-pr docs/content/get_started/pro/onprem/hardware_sizing.md:113: in the DD_DATABASE_WEB_LONG_STATEMENT_TIMEOUT row, make the Default column match the rows above it: "30 seconds under the service's harakiri, or 1740 when that is unset or 0".

Recommendation

Changes required: 1 open (a nit) on this PR. All five findings from the first verdict are confirmed fixed. Not approved or merged.

Not checked: the rendered page on the docs site.

[Maffooch]

Resolution of the second pass (issuecomment-6543325486)

• R1 fixed in e196797: the Default column of the DD_DATABASE_WEB_LONG_STATEMENT_TIMEOUT row now reads "30 seconds under the service's harakiri, or 1740 when that is unset or 0", like the two rows above it (docs/content/get_started/pro/onprem/hardware_sizing.md:113).

[Maffooch]

Adversarial review (re-check of e196797, docs only, tier light)

CI read: the checks that finished pass or skip; none failing.

Prior finding verified against the docs: OSS R1 (hardware_sizing.md:113 default text) is fixed. The settings table now says the default is 30 seconds under DD_UWSGI_HARAKIRI, or 1740 when it is unset or 0, for the web variable, the import variable and the long variable. That matches pool_ceiling (harakiri minus 30, 1770 when unset) in the paired Pro change. The prose (870 on dojo, 1740 on dojo-import-scan, imports capped at the same ceiling, background work unbounded) and the Kubernetes paragraph (shared env var across pools) agree with the code and the compose files. The PgBouncer warning is present.

Break attempts: (1) read the numbers in every sentence against the code defaults: consistent; (2) checked the table's "Docker Compose only" claim for the import variable against the compose edits (only compose maps DD_DATABASE_IMPORT_STATEMENT_TIMEOUT): consistent; (3) checked the text for customer data, em dashes and screenshots: none.

Not checked: the "From 3.5.0" release label against the milestone schedule, and docs build output.

Findings

No findings.

Recommendation: approve (0 open findings). Merge together with the Pro PR.