-
Notifications
You must be signed in to change notification settings - Fork 72
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
DSR 3.0 Bugfix: Approved -> Failed Privacy Requests Don't Change Status #4837
Conversation
…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.
The latest updates on your projects. Learn more about Vercel for Git ↗︎ 1 Ignored Deployment
|
.filter( | ||
PrivacyRequest.status.in_( | ||
[PrivacyRequestStatus.in_processing, PrivacyRequestStatus.approved] | ||
) | ||
) |
There was a problem hiding this comment.
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"
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This makes sense!
tests/conftest.py
Outdated
@@ -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, |
There was a problem hiding this comment.
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
@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( |
There was a problem hiding this comment.
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.
Passing run #7502 ↗︎
Details:
Review all test suite changes for PR #4837 ↗︎ |
…ametrization has been removed.
Codecov ReportAll modified and coverable lines are covered by tests ✅
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. |
There was a problem hiding this 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 ✅
Thank you for your review @galvana ⭐ |
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
👉 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
nox -s dev -- shell postgres
cd fides/clients
turbo run dev
Pre-Merge Checklist
CHANGELOG.md