-
Notifications
You must be signed in to change notification settings - Fork 9
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
PIR Database Migrations to Address Integrity Issues & Related Feature Flagger #2997
Conversation
…p, add tests and test data
… & vault creation for testability. Add tests & mocks. Remove some previous changes.
3a06484
to
f0a8e90
Compare
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.
It mostly looks good, although I haven't physically tested it yet since I've left quite a few comments (so would want to retest it if there are many changes)
It's a little difficult to review some of the database provider stuff because git gets confused with some things moving. It would be easier to review if it was separated out into multiple PRs. In future please do that, or we can discuss the PR strategy at the start of the project.
// Recreate tables to add correct foreign key constraints | ||
try recreateTablesV3(database: database) | ||
|
||
// As a precaution, re-run orphan deletion if necessary |
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.
In what case would this be necessary?
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 could not re-create any situation in which this is required. This was added to mitigate any unknown risks (of which I currently am unaware). We might feel this indicates lack of confidence in our approach. I don’t see it that way. I see it as an extra pre-caution to mitigate a possibly ‘high-risk’ migration.
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 think we're double dipping since we have this and "// As a precaution, explicitly check for any foreign key violations which were missed".
In general I think there are a lot of parts of the codebase that do things just in case and lots of them are nonsensical, so I do have an immediate visceral reaction to it.
I think I'm unconvinced it derisks it, because if it's necessary, what happened? What's broken? I assume something
I'm personally undecided on keeping it at the moment, but I do think it's worth more of a convo
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.
Understandable. I can’t see a way that foreign keys would be missed. To validate that we have:
- Implemented a orphan cleanup strategy which we believe won’t leave any integrity issues
- Added tests for this
- Put these changes through code review
So, we can remove this. However, if we do admit there is some risk in a migration (and most of the risk of failing comes from integrity checks IMO), and we are feature flagging and taking other precautions, I’m unsure where I sit with this one.
Cool, I’ll ping on MM for a conversation.
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.
We chatted about it sync and I'm fine with leaving it. It's well encapsulated, and a migration is essentially tech debt anyway...
...on/Sources/DataBrokerProtection/Storage/DataBrokerProtectionDatabaseMigrationsProvider.swift
Show resolved
Hide resolved
It will be removed via a PR to the release branch before the end of the internal testing week | ||
See: https://app.asana.com/0/0/1207876679488680/f | ||
*/ | ||
return true |
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 could see this going badly wrong as a strategy. Did we talk about it anywhere in asana?
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.
Understandable concern. It could go wrong, but I think risk can be mitigated with planning. No, we didn’t discuss in Asana, but that probably would have been a better first step here. I’ll remove this for now, and initiate a conversation in Asana.
Asana: Async Chat: Enabling the New Migrations for Internal Users
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’ve pushed an implementation for this. Note that I only added option 3 as discussed in Asana - the time-based check. This is all that is required.
...erProtection/Tests/DataBrokerProtectionTests/DataBrokerProtectionDatabaseProviderTests.swift
Show resolved
Hide resolved
...tion/Tests/DataBrokerProtectionTests/DataBrokerProtectionMigrationsFeatureFlaggerTests.swift
Show resolved
Hide resolved
...ion/Sources/DataBrokerProtection/Database/DataBrokerProtectionSecureVaultErrorReporter.swift
Show resolved
Hide resolved
...erProtection/Sources/DataBrokerProtection/Storage/DataBrokerProtectionDatabaseProvider.swift
Outdated
Show resolved
Hide resolved
...erProtection/Sources/DataBrokerProtection/Storage/DataBrokerProtectionDatabaseProvider.swift
Outdated
Show resolved
Hide resolved
...erProtection/Sources/DataBrokerProtection/Storage/DataBrokerProtectionDatabaseProvider.swift
Outdated
Show resolved
Hide resolved
Thanks for the thorough review and comments @THISISDINOSAUR , super useful. I’ve updated the PR and responded to all comments. Re: the difficulty in reviewing the PR - Totally agree. The nature of the changes and presentation in Git make it hard to review. Apologies for that. As you suggest a good approach here would have been to open separate PRs - maybe some early PRs with move-related changes. I’ll keep that in mind. I don’t think a specific PR strategy discussion would have helped in this case, as I really didn’t anticipate the types of changes we ended up with. However, maybe a general ‘PR Strategy’ discussion would have at least planted the seed to break up the PRs at a later stage. |
...tion/Sources/DataBrokerProtection/Storage/DataBrokerProtectionMigrationsFeatureFlagger.swift
Outdated
Show resolved
Hide resolved
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.
Testing works, so LGTM!
For prosperity, we also chatted at length on MM exactly what causes orphaned records happen to try and make sure any of this clean up shouldn't cause a problem. ( I was specifically checking for collisions with the weird "deprecated" data thing we do and if it could cause problems there).
I'm as happy as it's possible to be there, whilst acknowledging this work is always risky.
… Flagger (#2997) Task/Issue URL: https://app.asana.com/0/1206488453854252/1207806240565841/f Tech Design URL: https://app.asana.com/0/481882893211075/1207878066929518/f **Description**: This PR adds a v3 PIR database migration. This migration is intended solely to address PIR integrity issues.
Task/Issue URL: https://app.asana.com/0/1206488453854252/1207806240565841/f
Tech Design URL: https://app.asana.com/0/481882893211075/1207878066929518/f
Description: This PR adds a v3 PIR database migration. This migration is intended solely to address PIR integrity issues. We address these issues by:
Specific Changes Introduced:
DataBrokerProtectionDatabaseMigrationsProvider
DataBrokerProtectionDatabaseProvider
to enable creation based on the feature flag, and allow injection of the migrationsDataBrokerProtectionDatabaseProvider
DataBrokerProtectionDatabaseProvider.deleteProfileData
to delete all records.sql
database fileSteps to test this PR:
main
branch in Xcode, check PIR dashboard or debug DB viewer)102
ofDefaultDataBrokerProtectionDatabaseProvider
(so you can confirm that you were migrated to v3)Definition of Done:
—
Internal references:
Pull Request Review Checklist
Software Engineering Expectations
Technical Design Template
Pull Request Documentation