Skip to content

LG-9968 Switch back to fraud_review_pending_at to determine if a user is fraud review pending#8845

Merged
jmhooper merged 5 commits intomainfrom
jmhooper-start-using-fraud-pending-at-again
Jul 27, 2023
Merged

LG-9968 Switch back to fraud_review_pending_at to determine if a user is fraud review pending#8845
jmhooper merged 5 commits intomainfrom
jmhooper-start-using-fraud-pending-at-again

Conversation

@jmhooper
Copy link
Contributor

We recently changed the way we determine if a user is in fraud review. The change added a fraud_pending_reason column to a user to mark that they might require fraud review after address verification.

Users who verify their address by phone are marked fraud review pending right away. Users who verify their address by mail are only marked fraud review pending after they enter their OTP.

To allow us to change the way we manage the fraud timestamps we moved the reads that determine if a user is in fraud review to look for the presence of fraud_pending_reason. This maintained legacy behavior while allowing us to adjust writes on fraud_review_pending_at and backfilling.

Now that those reads and backfills are complete we can switch reads back to fraud_review_pending_at.

@jmhooper
Copy link
Contributor Author

Now that those reads and backfills are complete we can switch reads back to fraud_review_pending_at.

This is a lie. I am marking this do not merge until #8821 is deployed to production and we have run the backfill job.

@jmhooper
Copy link
Contributor Author

I also need to go through and update some specs that include the fraud_review_pending trait on the Profiles factory.

@jmhooper jmhooper marked this pull request as ready for review July 25, 2023 13:56
@jmhooper jmhooper requested a review from a team July 25, 2023 13:57
Copy link
Contributor

@soniaconnolly soniaconnolly left a comment

Choose a reason for hiding this comment

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

LGTM (have not tried it locally). Couple of queries.

jmhooper added 5 commits July 26, 2023 11:49
…er is fraud review pending

We recently changed the way we determine if a user is in fraud review. The change added a `fraud_pending_reason` column to a user to mark that they might require fraud review after address verification.

Users who verify their address by phone are marked fraud review pending right away. Users who verify their address by mail are only marked fraud review pending after they enter their OTP.

To allow us to change the way we manage the fraud timestamps we moved the reads that determine if a user is in fraud review to look for the presence of `fraud_pending_reason`. This maintained legacy behavior while allowing us to adjust writes on `fraud_review_pending_at` and backfilling.

Now that those reads and backfills are complete we can switch reads back to `fraud_review_pending_at`.

[skip changelog]
@jmhooper jmhooper force-pushed the jmhooper-start-using-fraud-pending-at-again branch from 5fa13a5 to bf9d25b Compare July 26, 2023 15:52
@jmhooper jmhooper merged commit 93ecd59 into main Jul 27, 2023
@jmhooper jmhooper deleted the jmhooper-start-using-fraud-pending-at-again branch July 27, 2023 14:16
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.

3 participants