Page MenuHomePhabricator

[lib] Separate `serverThreadFrozenDueToBlock` and `clientThreadFrozenDueToBlock`
AbandonedPublic

Authored by atul on Mar 12 2024, 8:56 AM.
Tags
None
Referenced Files
F4958298: D11311.id38024.diff
Sat, Mar 22, 10:41 PM
Unknown Object (File)
Tue, Mar 4, 3:08 PM
Unknown Object (File)
Tue, Feb 25, 12:28 PM
Unknown Object (File)
Sat, Feb 22, 1:31 AM
Unknown Object (File)
Sat, Feb 22, 1:31 AM
Unknown Object (File)
Sat, Feb 22, 1:31 AM
Unknown Object (File)
Sat, Feb 22, 1:31 AM
Unknown Object (File)
Fri, Feb 21, 6:10 AM
Subscribers

Details

Summary

Updating all of the threadFrozenDueToBlock callsites on keyserver is going to be involved. I started working on it, but it required changing a bunch of functionality in keyserver/lib/etc.

I will still consolidate the logic in this stack, specifically to avoid the sketchy CHANGE_ROLE check for server variant of function... but will sequence that after figuring out everything on client.


Depends on D11308

Test Plan

Straightforward refactor, find/replace + flow

Diff Detail

Repository
rCOMM Comm
Branch
master
Lint
No Lint Coverage
Unit
No Test Coverage

Event Timeline

atul requested review of this revision.Mar 12 2024, 9:11 AM

Separate serverThreadFrozenDueToBlock and clientThreadFrozenDueToBlock

Why do we want to do that?

lib/shared/thread-utils.js
1053

Should we move this function to keyserver?

This revision is now accepted and ready to land.Mar 19 2024, 5:04 AM

We ended up going with a very different approach from this stack. Abandoning to tidy things up.