audit_file_detail renders the entire raw_text and every event row inline, unbounded

[erskingardner]

Impact

The audit file detail view builds a single HTML page containing (a) the file's entire raw_text — up to GOGGLES_MAX_DUMP_BYTES (50 MiB by default) — in one <pre>, and (b) a fully rendered table row for every AuditEvent in the file. For a large forensic upload this produces a very large HTML response and a correspondingly large in-memory render, on every page load, tying up a worker and pushing tens of MB to the browser (which then has to lay it all out).

There is no pagination, truncation, or lazy loading; the cost scales with the size of the uploaded file.

Code pointers

• forensics/views.py:93 — audit_file_detail() loads prefetch_related("events__group") and builds event_rows = [event_row(event) for event in audit_file.events.all()] (all events).
• forensics/templates/forensics/audit_file_detail.html:92 — renders a <tr> per event with no limit.
• forensics/templates/forensics/audit_file_detail.html:140 — <pre class="well">{{ audit_file.raw_text }}</pre> dumps the full raw upload.

Expected behavior

The detail page should stay responsive regardless of upload size — large files should be paginated, truncated with a "show more"/download affordance, or streamed.

Suggested fix

• Paginate the events table (and/or load it lazily).
• Truncate the inline raw JSONL preview to the first N KB with a link to download the full raw_text separately, rather than inlining up to 50 MiB.
• Consider a query-count / response-size regression test for a large file.