[keyserver] Introduce migration to regenerate KNOW_OF relationships
ClosedPublic
Actions

Authored by ashoat on Aug 22 2024, 2:32 PM.

Details

Reviewers

will
varun

Commits

rCOMMcbb0023df156: [keyserver] Introduce migration to regenerate KNOW_OF relationships

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

Branch

ashoat/permissions

Lint

No Lint Coverage

Unit

No Test Coverage

Event Timeline

ashoat created this revision.Aug 22 2024, 2:32 PM

Herald added a subscriber: tomek. · View Herald TranscriptAug 22 2024, 2:32 PM

ashoat added inline comments.Aug 22 2024, 2:34 PM

keyserver/src/database/migration-config.js
913	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	This logic is similar to what we do here