Page MenuHomePhabricator

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

Authored by atul on Mar 12 2024, 8:56 AM.
Tags
None
Referenced Files
Unknown Object (File)
Fri, Nov 8, 6:46 AM
Unknown Object (File)
Oct 15 2024, 8:18 PM
Unknown Object (File)
Oct 15 2024, 8:17 PM
Unknown Object (File)
Oct 15 2024, 8:17 PM
Unknown Object (File)
Oct 15 2024, 8:17 PM
Unknown Object (File)
Sep 4 2024, 2:26 PM
Unknown Object (File)
Sep 4 2024, 2:26 PM
Unknown Object (File)
Sep 4 2024, 2:26 PM
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.