-
Notifications
You must be signed in to change notification settings - Fork 4.2k
fix!: redacting user retirement data in lms #37886
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
Open
ktyagiapphelix2u
wants to merge
6
commits into
openedx:master
Choose a base branch
from
ktyagiapphelix2u:ktyagi/redaction
base: master
Could not load branches
Branch not found: {{ refName }}
Loading
Could not load tags
Nothing to show
Loading
Are you sure you want to change the base?
Some commits from the old base branch may be removed from the timeline,
and old review comments may become outdated.
+92
−4
Open
Changes from all commits
Commits
Show all changes
6 commits
Select commit
Hold shift + click to select a range
19fc427
fix: redacting user retirement data in lms
ktyagiapphelix2u 5ac51b6
fix: redacting user retirement data in lms
ktyagiapphelix2u b0e4bce
fix: redacting user retirement data in lms
ktyagiapphelix2u 3c338d4
fix: redacting user retirement data in lms
ktyagiapphelix2u 5972c46
fix: redacting user retirement data in lms
ktyagiapphelix2u 83e52e1
fix: redacting user retirement data in lms
ktyagiapphelix2u File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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.
Thanks @ktyagiapphelix2u. I'm glad you were able to confirm the updates are happening with
assertNumQueries. I know I'm being picky here, but I don't want to lose the assertions that the redacting is happening do the correct fields using the specific custom redacted values.If you peak under the covers of
assertNumQueries, it is using CaptureQueriesContext. You can see how our custom implementation ofassertNumQueriesreviews the queries to pull out queries for certain ignore-tables.Could you try using
CaptureQueriesContextin place ofassertNumQueries, and ensure that the queries are found with the appropriate updates? I thinkassert retirements.count() == 0is enough for asserting that the deletes happened, and we can assume they happen after the updates, or otherwise the updates would have failed (maybe)? You could try swapping the.save()and.delete()line to see what happens, and see if this needs its own assertion.Hopefully this makes sense. Thank you.
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.
Yeah @robrap, that make sense so i have implemented using CaptureQueriesContext and tested them so these 3 cased now what i see is-
Case 1: Correct Order (SAVE then DELETE)
We call .save() to execute 9 UPDATE queries redacting PII, then .delete() to execute 9 DELETE queries. The MySQL binlog captures both: UPDATE with redacted data first, then DELETE, so Fivetran syncs safely redacted PII to Snowflake.
Case 2: Swapped Broken Order (DELETE then SAVE)
We call .delete() to remove records, then .save() fails because records no longer exist, resulting in 0 UPDATE queries. PII never gets redacted and Fivetran syncs original sensitive data to Snowflake.
Case 3: Why Tests Fail
Tests assert 9 UPDATE queries should execute. When order is swapped, they find 0 instead, failing with "assert 9 == 0" and proving the importance of redacting before deleting.