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
Details
- Reviewers
michal kamil ginsu - Commits
- rCOMM77d318ecbe9f: [lib] Hash new threads on keyserver login
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
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.
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.