[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

Lint

Lint Not Applicable

Unit

Tests Not Applicable

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 ↗	(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