[lib] Hash new threads on keyserver login
ClosedPublic
Actions

Authored by inka on Jan 5 2024, 3:31 AM.

Details

Reviewers

michal
kamil
ginsu

Commits

rCOMM77d318ecbe9f: [lib] Hash new threads on keyserver login

Summary

issue: ENG-5820
When we log in to a keyserver, we want to hash the new threads. So we set threadHashingStatus to starting. Then in the handler, which takes threads and creates batches to be hashed, we filter out the threads that are already present in the integrity store, and only hash the new ones. Since threadHashingStatus was only ever set to starting on login (or in default state, but then the hashes are an empty object), this doesn't break anything.
There is no need to hash threads on identity login, since identity provides no data on threads

Test Plan

Tested that when a user logs into the app all threads are hashed.
Tested that when keyserverAuthActionTypes.success is dispatched and has a new thread in payload, this thread and only this thread is hashed.

Diff Detail

Repository

rCOMM Comm

Lint

Lint Not Applicable

Unit

Tests Not Applicable

Event Timeline

inka created this revision.Jan 5 2024, 3:31 AM

Herald added subscribers: tomek, ashoat. · View Herald TranscriptJan 5 2024, 3:31 AM

inka added a parent revision: D10531: [lib][web][native] Return current calendar query in logInExtraInfo.Jan 5 2024, 3:31 AM

inka added 1 blocking reviewer(s): michal.

inka added a child revision: D10552: [lib] Reduce notAcknowledgedPolicies on keyserver login.Jan 5 2024, 3:46 AM

Harbormaster completed remote builds in B25536: Diff 35289.Jan 5 2024, 3:49 AM

inka requested review of this revision.Jan 5 2024, 3:49 AM

Does your updated code already separate out only the threads from the newly logged-in keyserver for hashing? If not, is there a task that tracks updating the logic to work for multi-keyserver?

LGTM

Does your updated code already separate out only the threads from the newly logged-in keyserver for hashing?

From what I can see @inka schedules for hashing only the threads which currently don't have a hash which makes sense. I don't think we need to have a separate IntegrityHandler for each keyserver.

This revision is now accepted and ready to land.Jan 8 2024, 3:16 AM

It's like @michal says - we check for threads that are not yet present in the store, and only create hashes for them. So the flow is: user logs in to a new keyserver, and get new threads -> threadHashingStatus is set to starting -> the handler filters out all threads that are already in the store and only hashes our new threads.

This doesn't break the old behaviour, because in all other cases when we set threadHashingStatus to starting, we also set threadHashes to empty object, so no threads get filtered out.