Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

DSR 3.0 Bugfix: Approved -> Failed Privacy Requests Don't Change Status #4837

Merged
merged 6 commits into from
Apr 29, 2024

Conversation

pattisdr
Copy link
Contributor

@pattisdr pattisdr commented Apr 26, 2024

Closes #PROD-2005

Description Of Changes

Specifically, if manual request approval is required and the privacy request fails, the Privacy Request can get stuck in an approved state. While I tested the "manual request approval" flag in development, the large majority of the "error" testing was done with no approval required. Good find by Roger!

Code Changes

  • Update the existing polling task that checks for Privacy Requests whose sub-tasks have all had a chance to run, but some are errored, and transitions the Privacy Request to "Error" to also look for the "Approved" status.
    👉 Privacy Requests that are in-flight are expected to be in a "In-Processing" or "Approved" status, and I was only covering the first case.

Steps to Confirm

  • Setup DSR 3.0 and require manual request approval. The worker doesn't specifically need to be running here, you don't need parallelization to hit this case.
[execution]
require_manual_request_approval = true
use_dsr_3_0 = true
  • nox -s dev -- shell postgres
  • cd fides/clients
  • turbo run dev
  • Add a postgres integration in the frontend with a bad secret.
  • Submit a Privacy Request through the Privacy Center.
  • Previously, this would hang indefinitely in Approved. Now, this will hang briefly, but at the next poll, (check your terminal), you should see something like:

“Polling for privacy requests awaiting errored status change”
Marking access step of pri_f1433833-31ed-4d6f-b5d9-e415f1e18b1a as error

  • This will mark the Privacy Request as errored.
  • Fix the secret
  • Reprocess the privacy request
  • It should complete

Pre-Merge Checklist

  • All CI Pipelines Succeeded
  • Documentation (not needed)
  • Issue Requirements are Met
  • Relevant Follow-Up Issues Created
  • Update CHANGELOG.md

…oth IN_PROCESSING and APPROVED privacy requests to see if they have failing Request Tasks.

If a Privacy Request needed manual approval failed during processing, it could hang in the "Approved" state, because the polling process wasn't expecting this status.
If a Privacy Request is hanging out in a Pending status it is likely awaiting approval.  Privacy Requests that don't need approval are queued immediately and are transitioned to in-processing.  If a Privacy Request is approved, it is queued and not transitioned to in-processing. Both of these states can indicate a Privacy Request that is in-flight.
…s sporadically on DSR 3.0 - I just don't think this is a good test.
Copy link

vercel bot commented Apr 26, 2024

The latest updates on your projects. Learn more about Vercel for Git ↗︎

1 Ignored Deployment
Name Status Preview Comments Updated (UTC)
fides-plus-nightly ⬜️ Ignored (Inspect) Visit Preview Apr 29, 2024 2:32pm

Comment on lines +198 to +202
.filter(
PrivacyRequest.status.in_(
[PrivacyRequestStatus.in_processing, PrivacyRequestStatus.approved]
)
)
Copy link
Contributor Author

@pattisdr pattisdr Apr 26, 2024

Choose a reason for hiding this comment

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

This is the fix: an important detail I missed is that a Privacy Request that is actively in-flight, can have a status of "In Processing" or "Approved", not just "In Processing"

Copy link
Contributor

Choose a reason for hiding this comment

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

This makes sense!

@@ -35,6 +31,8 @@
from fides.api.main import app
from fides.api.models.privacy_request import (
EXITED_EXECUTION_LOG_STATUSES,
generate_request_callback_pre_approval_jwe,
generate_request_callback_resume_jwe,
Copy link
Contributor Author

Choose a reason for hiding this comment

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

Just applying the results of nox -s static_checks

Comment on lines +449 to 451
@pytest.mark.usefixtures("use_dsr_2_0")
@pytest.mark.asyncio
@pytest.mark.parametrize(
"dsr_version",
["use_dsr_3_0", "use_dsr_2_0"],
)
async def test_run_disabled_collections_in_progress(
Copy link
Contributor Author

@pattisdr pattisdr Apr 26, 2024

Choose a reason for hiding this comment

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

I am removing running this flaky test on DSR 3.0. This test was written for DSR 2.0 but it fails occasionally on CI for DSR 3.0. It is hard to reproduce when you run unit tests locally, you have to be running Python 3.8.x, and it will maybe fail 1/20 of the time, although it fails more frequently in CI. I just don't think this is a good test here.

@pattisdr pattisdr requested a review from galvana April 26, 2024 23:04
Copy link

cypress bot commented Apr 26, 2024

Passing run #7502 ↗︎

0 4 0 0 Flakiness 0
⚠️ You've recorded test results over your free plan limit.
Upgrade your plan to view test results.

Details:

Merge e989d40 into 5b4983d...
Project: fides Commit: e6a796a56e ℹ️
Status: Passed Duration: 00:36 💡
Started: Apr 29, 2024 2:44 PM Ended: Apr 29, 2024 2:45 PM

Review all test suite changes for PR #4837 ↗︎

Copy link

codecov bot commented Apr 27, 2024

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 86.87%. Comparing base (5b4983d) to head (e989d40).

Additional details and impacted files
@@           Coverage Diff           @@
##             main    #4837   +/-   ##
=======================================
  Coverage   86.87%   86.87%           
=======================================
  Files         345      345           
  Lines       20856    20856           
  Branches     2727     2727           
=======================================
  Hits        18119    18119           
  Misses       2262     2262           
  Partials      475      475           

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

@galvana
Copy link
Contributor

galvana commented Apr 29, 2024

Verified the privacy request status is set to Approved and that the job detects the errored request
image

2024-04-29 08:51:42 2024-04-29 15:51:42.991 | DEBUG    | fides.api.service.privacy_request.request_service:poll_for_exited_privacy_request_tasks:190 - Polling for privacy requests awaiting errored status change
2024-04-29 08:51:43 2024-04-29 15:51:43.021 | INFO     | fides.api.service.privacy_request.request_service:poll_for_exited_privacy_request_tasks:233 - Marking access step of pri_f32ab96e-05a7-420f-abe9-0cd745d84014 as error
image

Reprocessed successfully!
image

I also verified that the request goes to error if the integration isn't fixed but the request is reprocessed.

Copy link
Contributor

@galvana galvana left a comment

Choose a reason for hiding this comment

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

The change makes sense and I was able to verify this locally ✅

@pattisdr
Copy link
Contributor Author

Thank you for your review @galvana

@pattisdr pattisdr merged commit 29dd36a into main Apr 29, 2024
42 checks passed
@pattisdr pattisdr deleted the PROD-2005_approved_privacy_requests_that_error branch April 29, 2024 16:03
@cypress cypress bot mentioned this pull request Apr 29, 2024
31 tasks
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