Skip to content

[ENG-2613] Make privacy request diagnostics endpoint return download URL instead of direct json payload#7481

Merged
nreyes-dev merged 9 commits intomainfrom
nreyes/eng-2613
Feb 26, 2026
Merged

[ENG-2613] Make privacy request diagnostics endpoint return download URL instead of direct json payload#7481
nreyes-dev merged 9 commits intomainfrom
nreyes/eng-2613

Conversation

@nreyes-dev
Copy link
Contributor

@nreyes-dev nreyes-dev commented Feb 24, 2026

Make privacy request diagnostics endpoint return download URL instead of direct json payload

Ticket ENG-2613

Description Of Changes

Endpoint behavior change

Before: GET /privacy-request/{privacy_request_id}/diagnostics returns the diagnostics JSON payload directly.
New: the endpoint generates a ZIP file, uploads it to storage, and returns a JSON response containing a downloadable URL (freshly generated signed/presigned URL) rather than returning the full diagnostics inline.

Refactor: module split / code organization

The diagnostics feature has been reorganized into a dedicated module for clearer separation of concerns:

  • src/fides/service/privacy_request/privacy_request_diagnostics.py → moved into src/fides/service/privacy_request/diagnostics/gather.py (data-gathering logic)
  • New package: src/fides/service/privacy_request/diagnostics/
    • schemas.py: Pydantic schemas for non-PII diagnostics payload + export response
    • gather.py: DB/query helpers to assemble the diagnostics payload
    • export.py: ZIP serialization + upload + signed URL generation
    • exceptions.py: DefaultStorageNotConfiguredError
    • __init__.py: re-exports the public API

StorageConfig selection (behavior change)

Diagnostics exports now use the active default storage configuration via get_active_default_storage_config(db).

Artifact naming and storage key layout

Always upload a ZIP named like:

privacy-request-diagnostics/{privacy_request_id}/{timestamp}-{random}.zip

  • Timestamp is filesystem-safe (e.g. 20260226T185655Z)
  • Random suffix avoids same-second collisions

Unit Tests

Updated existing diagnostics endpoint tests to assert:

  • response contains download_url (and not the full JSON payload)
  • 422 behavior when default storage isn’t configured
  • happy path still produces a ZIP containing diagnostics.json and excludes raw identity values

Steps to Confirm

  1. Ensure an active default storage backend is configured
  2. Call GET /privacy-request/{privacy_request_id}/diagnostics for any existing privacy_request_id.
  3. Assert response includes download_url, object_key, and storage_type.
  4. Call the endpoint twice for the same privacy_request_id and confirm a new export is generated each time (different object_key) and the URL is freshly generated each time.
  5. Clear/unset default storage configuration and verify the endpoint returns 422 with a configuration hint.

Pre-Merge Checklist

  • Issue requirements met
  • All CI pipelines succeeded
  • CHANGELOG.md updated
    • Add a db-migration This indicates that a change includes a database migration label to the entry if your change includes a DB migration
    • Add a high-risk This issue suggests changes that have a high-probability of breaking existing code label to the entry if your change includes a high-risk change (i.e. potential for performance impact or unexpected regression) that should be flagged
    • Updates unreleased work already in Changelog, no new entry necessary
  • UX feedback:
    • All UX related changes have been reviewed by a designer
    • No UX review needed
  • Followup issues:
    • Followup issues created
    • No followup issues
  • Database migrations:
    • Ensure that your downrev is up to date with the latest revision on main
    • Ensure that your downgrade() migration is correct and works
      • If a downgrade migration is not possible for this change, please call this out in the PR description!
    • No migrations
  • Documentation:
    • Documentation complete, PR opened in fidesdocs
    • Documentation issue created in fidesdocs
    • If there are any new client scopes created as part of the pull request, remember to update public-facing documentation that references our scope registry
    • No documentation updates required

@vercel
Copy link
Contributor

vercel bot commented Feb 24, 2026

The latest updates on your projects. Learn more about Vercel for GitHub.

2 Skipped Deployments
Project Deployment Actions Updated (UTC)
fides-plus-nightly Ignored Ignored Preview Feb 26, 2026 7:39pm
fides-privacy-center Ignored Ignored Feb 26, 2026 7:39pm

Request Review

@nreyes-dev nreyes-dev marked this pull request as ready for review February 24, 2026 19:39
@nreyes-dev nreyes-dev requested a review from a team as a code owner February 24, 2026 19:39
@nreyes-dev nreyes-dev requested review from JadeCara and galvana and removed request for a team February 24, 2026 19:39
@greptile-apps

This comment was marked as resolved.

Copy link
Contributor

@greptile-apps greptile-apps bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

6 files reviewed, 1 comment

Edit Code Review Agent Settings | Greptile

@nreyes-dev
Copy link
Contributor Author

@greptileai re-review pls

Copy link
Contributor

@greptile-apps greptile-apps bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

6 files reviewed, 5 comments

Edit Code Review Agent Settings | Greptile

@greptile-apps

This comment was marked as resolved.

@nreyes-dev nreyes-dev added this pull request to the merge queue Feb 26, 2026
Merged via the queue into main with commit f04263e Feb 26, 2026
53 of 54 checks passed
@nreyes-dev nreyes-dev deleted the nreyes/eng-2613 branch February 26, 2026 22:20
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants