Skip to main content

File Result Retention

RepoRisk keeps individual file results by default. Retaining them lets you review file-level findings later and can reduce the cost of future scans when unchanged content is reused.

When to use deletion

Deleting file results is an advanced privacy option intended for sensitive codebases that are not open source or otherwise publicly accessible. It is not recommended for most repositories.

When enabled:

  • RepoRisk generates and saves the repository report before removing repository-unique file results.
  • The report's aggregate scores, finding counts, summary, and other report-level information remain available.
  • File inventory entries remain visible, but deleted file details are shown as removed rather than as a successful zero-finding analysis.
  • If repository analysis fails, repository-only source and partial file results are removed after the failure becomes terminal.
  • Results are preserved when the same file hash is also used by another repository, such as a common open source library.
  • A future scan may need to analyze deleted files again, which can increase cost and processing time.

Line-of-code approval and other recoverable pauses are not terminal failures and do not trigger deletion.

Enable the option for a new submission

  1. Open Submit for Analysis.
  2. Expand Advanced options.
  3. Turn on Delete repository-unique file results after the report is generated, or if analysis fails.
  4. Read and confirm the warning.
  5. Submit the repository, package, extension, or ZIP file normally.

The option is off by default. Merely expanding Advanced options does not enable it.

Change an existing repository

  1. Open the repository status page.
  2. Expand Advanced options.
  3. Change the file-result deletion setting and select Save privacy setting.
  4. When enabling deletion, confirm the warning. You may also request cleanup of the current completed report.

Changing the setting applies prospectively to new scan runs. A scan snapshots the setting when it starts, so a mid-scan change does not alter that scan's cleanup behavior.

Troubleshooting

Cleanup is durable and retried automatically. If a cleanup cannot be completed after repeated attempts, RepoRisk records a failed cleanup state instead of claiming that the file results were removed.

Cleanup after failed analysis is always tied to the originating scan. RepoRisk rejects cleanup work that lacks that scan reference, preventing it from affecting inventory from other scans.

A later successful scan supersedes an older completed-report cleanup request. A later failed scan does not, so the requested cleanup can still proceed.

No-change report refreshes retain their terminal status and enqueue their own cleanup when the scan opted into repository-unique file-result deletion, so superseded cleanup work does not leave unique results behind. If another report is already being generated, the no-change refresh is requeued after that report releases the repository lock.

The repository page continues checking cleanup status after report generation finishes until the work completes or fails, so queued work and retries remain current while older refresh responses cannot replace a newly saved cleanup state or overwrite an unsaved privacy-setting change.

If file details are marked removed, use the report-level findings for review or run a new scan to regenerate individual results.