-
Notifications
You must be signed in to change notification settings - Fork 84
Adding more exception handling to the privacy request flow #7233
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
base: main
Are you sure you want to change the base?
Conversation
|
The latest updates on your projects. Learn more about Vercel for GitHub. 2 Skipped Deployments
|
Greptile SummaryThis PR improves error visibility and handling throughout the privacy request lifecycle by adding execution log entries and proper error state transitions when failures occur during scheduling, processing, and post-processing steps. Key improvements:
Issues to address before merging:
Confidence Score: 4/5
Important Files Changed
|
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.
3 files reviewed, 3 comments
src/fides/api/service/privacy_request/request_runner_service.py
Outdated
Show resolved
Hide resolved
JadeCara
left a comment
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.
Cursor beat me to it but the temp code to cause an error should probably be removed before merging - other than that looks good to me.
Co-authored-by: greptile-apps[bot] <165735046+greptile-apps[bot]@users.noreply.github.com>
Ticket ENG-2403
Description Of Changes
This PR improves error visibility for privacy request scheduling and processing failures. Previously, when a privacy request failed to schedule (e.g., due to memory limits or Celery issues) or failed during post-processing steps, the request would get stuck in an invalid state without any indication in the activity timeline of what went wrong.
Key improvements:
errorstatus with a descriptive entry in the activity timelinerun_privacy_requestnow log descriptive errors to the activity timelineCode Changes
Backend - Scheduling error handling (
privacy_request_service.py):_handle_scheduling_failurehelper to mark privacy requests as errored and create execution log entries_log_scheduling_successhelper to create success execution log entries when scheduling succeedsqueue_privacy_requestin try/except to catch and handle scheduling failures_process_privacy_request_restartto raiseHTTPExceptionwith the actual error message on failurehandle_approvalto catch and log scheduling failures during initial request creationBackend - Processing error handling (
request_runner_service.py):MisconfiguredPolicyException(policy has no rules)BaseExceptioncatch-all in the main processing try blockClientUnsuccessfulExceptionandPydanticValidationError)Frontend (
useReprocessPrivacyRequest.ts):else ifblock that checked forerror_messagein the response - no longer needed since the backend now raises anHTTPExceptionwith the error message instead of returning a 200 with error statusFrontend (
RequestDetails.tsx):Frontend (
types.ts):error_messagefield fromPrivacyRequestEntitytypeSteps to Confirm
The tests should still pass. This PR is more to help troubleshoot stuck privacy requests that don't have any clear errors.
Pre-Merge Checklist
CHANGELOG.mdupdatedmaindowngrade()migration is correct and works