Skip to content

Conversation

@JadeCara
Copy link
Contributor

@JadeCara JadeCara commented Oct 30, 2025

Ticket ENG-1740

Description Of Changes

🎯 Whenever we try to read identities or custom privacy request fields from Redis, fallback to getting the data from the database if the values have already expired.

Refer to the updates to get_cached_identity_data and get_cached_custom_privacy_request_fields in this closed PR Privacy request cache refresh by galvana · Pull Request #4610 · ethyca/fides

Code Changes

  • Added fallback query for identities and custom fields to privacy request
  • Added new function to verify if identity is cached for existing endpoint call
  • Added some tests for this fallback functionality.

Steps to Confirm

  1. Run fidesplus pointed at this branch.
  2. To allow us to manipulate the cache before our privacy request completes - Set auto approve to false using PATCH /api/v1/config with:
{
  "execution": {
    "require_manual_request_approval": true
  }
}
  1. Create a privacy request and grab the id
  2. using the local redis login redis-cli -a your_password
  3. delete the identity keys DEL id-<<privacy_request_id here>>-identity-email
  4. Verify its gone by running KEYS * to verify that key is gone
  5. approve the privacy request and verify it runs and that the logs contain:
fidesplus-worker-generic-1  | 2025-11-04 03:14:02.788 | DEBUG    | fides.api.models.privacy_request.privacy_request:get_cached_identity_data:710 - Cache miss for request pri_08f0df9c-6cb7-44aa-9228-3f662e19657c, falling back to DB | {'privacy_request_id': 'pri_08f0df9c-6cb7-44aa-9228-3f662e19657c', 'privacy_request_source': 'Request Manager'}

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

vercel bot commented Oct 30, 2025

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

Project Deployment Preview Comments Updated (UTC)
fides-plus-nightly Ready Ready Preview Comment Nov 4, 2025 10:04pm
1 Skipped Deployment
Project Deployment Preview Comments Updated (UTC)
fides-privacy-center Ignored Ignored Nov 4, 2025 10:04pm

Jade Wibbels and others added 2 commits October 31, 2025 15:12
@codecov
Copy link

codecov bot commented Oct 31, 2025

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 87.29%. Comparing base (eb3f579) to head (0849a89).
⚠️ Report is 5 commits behind head on main.

Additional details and impacted files
@@           Coverage Diff           @@
##             main    #6896   +/-   ##
=======================================
  Coverage   87.29%   87.29%           
=======================================
  Files         523      523           
  Lines       34172    34188   +16     
  Branches     3932     3934    +2     
=======================================
+ Hits        29829    29845   +16     
  Misses       3487     3487           
  Partials      856      856           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
  • 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

@JadeCara JadeCara marked this pull request as ready for review November 4, 2025 01:16
@JadeCara JadeCara requested a review from a team as a code owner November 4, 2025 01:16
@JadeCara JadeCara requested review from erosselli and removed request for a team November 4, 2025 01:16
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.

Greptile Overview

Greptile Summary

Implements fallback logic to retrieve identity and custom privacy request fields from the database when Redis cache expires, preventing privacy requests from failing when cached data is no longer available.

Key changes:

  • Added verify_cache_for_identity_data() method to check if identity data exists in cache without triggering fallback
  • Enhanced get_cached_identity_data() to automatically fetch from DB and re-cache when cache miss occurs
  • Enhanced get_cached_custom_privacy_request_fields() with similar fallback behavior
  • Updated restart endpoint to use verification method instead of retrieval method for cache checking
  • Added comprehensive test coverage for fallback scenarios

Test improvements:

  • Removed manual cache deletion in test fixtures, following best practices (f4371da8)
  • Added tests for both successful fallback and edge cases (no persisted identity)

Confidence Score: 5/5

  • This PR is safe to merge with minimal risk
  • The implementation is straightforward and defensive - adding fallback logic that prevents failures when cache expires. The changes are well-tested with multiple test cases covering edge cases. No breaking changes or risky refactoring. The endpoint change correctly delegates to a new verification method that doesn't trigger side effects.
  • No files require special attention

Important Files Changed

File Analysis

Filename Score Overview
src/fides/api/models/privacy_request/privacy_request.py 4/5 Added fallback logic to retrieve identity and custom fields from DB when Redis cache expires, plus helper method to verify cache presence
src/fides/api/api/v1/endpoints/privacy_request_endpoints.py 5/5 Updated restart endpoint to use new verify_cache_for_identity_data() method instead of get_cached_identity_data() for cache verification
tests/ops/models/privacy_request/test_privacy_request.py 5/5 Added comprehensive tests for cache fallback behavior for identity and custom privacy request fields

4 files reviewed, no comments

Edit Code Review Agent Settings | Greptile

Comment on lines 697 to 699
prefix = f"id-{self.id}-identity-*"
cache: FidesopsRedis = get_cache()
keys = cache.keys(prefix)
Copy link
Contributor

Choose a reason for hiding this comment

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

maybe we can move these 3 lines to a private method that we can reuse in this verify_cache_for_identity_data function and also in get_cached_identity_data ?

Comment on lines -81 to -93
@pytest.fixture(scope="function")
def third_privacy_request_awaiting_erasure_email_send(
db: Session, erasure_policy: Policy
) -> PrivacyRequest:
"""Add a third erasure privacy request w/ no identity in this state for these tests"""
privacy_request = _create_privacy_request_for_policy(
db,
erasure_policy,
)
privacy_request.status = PrivacyRequestStatus.awaiting_email_send
privacy_request.save(db)
yield privacy_request
privacy_request.delete(db)
Copy link
Contributor

Choose a reason for hiding this comment

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

what's the reason for deleting this fixture ?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

It is un-used with the changes. The _create_privacy_request_for_policy persists and identity and in the tests we were deleting it. That doesn't really work for the tests anymore since we just go get it from the db now.

@JadeCara JadeCara requested a review from erosselli November 4, 2025 20:58
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.

3 participants