Page MenuHomePhabricator

[keyserver] Introduce migration to regenerate KNOW_OF relationships
ClosedPublic

Authored by ashoat on Thu, Aug 22, 2:32 PM.
Tags
None
Referenced Files
Unknown Object (File)
Tue, Sep 17, 5:49 PM
Unknown Object (File)
Sun, Sep 15, 11:52 AM
Unknown Object (File)
Fri, Sep 13, 1:00 PM
Unknown Object (File)
Fri, Sep 6, 5:01 PM
Unknown Object (File)
Thu, Sep 5, 11:49 AM
Unknown Object (File)
Thu, Sep 5, 5:50 AM
Unknown Object (File)
Wed, Sep 4, 12:20 AM
Unknown Object (File)
Sat, Aug 31, 6:41 PM
Subscribers

Details

Summary

As a result of running the recent migration with, we inadvertently created KNOW_OF relationships between each pair of users.

This occurred because each user got a memberships row in each thread in GENESIS, even though they were not a member. That's because their member_ permissions got cascaded down to all threads because of D13113.

To get around this, I deleted all KNOW_OF relationships in production, and regenerated them using this migration.

More details in ENG-9075.

Test Plan

I ran this in production. Before I ran it there were 563736 KNOW_OF relationships. After running it there were only 31617

Diff Detail

Repository
rCOMM Comm
Lint
Lint Not Applicable
Unit
Tests Not Applicable

Event Timeline

keyserver/src/database/migration-config.js
913 ↗(On Diff #43596)

We exclude GENESIS because we don't create KNOW_OF relationships based on users being in GENESIS. See here

We do that to avoid having a relationship between ever pair of users. Since users can't send messages, react, or do anything in GENESIS, the relationship is not necessary

927 ↗(On Diff #43596)

This logic is similar to what we do here

ashoat published this revision for review.Thu, Aug 22, 2:35 PM
This revision is now accepted and ready to land.Thu, Aug 22, 2:39 PM
This revision was landed with ongoing or failed builds.Thu, Aug 22, 2:43 PM
This revision was automatically updated to reflect the committed changes.