[lib] Deprecate `minimallyEncodeRawThreadInfo`
ClosedPublic
Actions

Authored by atul on Thu, Jul 11, 1:27 PM.

Details

Reviewers

ashoat

Commits

rCOMM2ab735a4abc7: [lib] Deprecate `minimallyEncodeRawThreadInfo`

Summary

We want to freeze existing logic for use in migration and rawThreadInfoFromServerThreadInfo while making it clear that it shouldn't be used in the future.

Depends on D12597

Test Plan

Just a rename.

Diff Detail

Repository

rCOMM Comm

Lint

Lint Not Applicable

Unit

Tests Not Applicable

Event Timeline

atul created this revision.Thu, Jul 11, 1:27 PM

Herald added a subscriber: tomek. · View Herald TranscriptThu, Jul 11, 1:27 PM

Harbormaster returned this revision to the author for changes because remote builds failed.Thu, Jul 11, 1:40 PM

Harbormaster failed remote builds in B30294: Diff 42242!

atul requested review of this revision.Thu, Jul 11, 2:16 PM

Just two questions:

We want to freeze existing logic for use in migration and rawThreadInfoFromServerThreadInfo while making it clear that it shouldn't be used in the future.

First: is rawThreadInfoFromServerThreadInfo just for the shimming logic that handles old clients?

Second: it looks like there's a Flow error here that doesn't show up in the parent diff. Any context?

This revision now requires changes to proceed.Thu, Jul 11, 5:20 PM

atul edited parent revisions, added: D12722: [lib] Add `invariant` to suppress `flow` issue in `getPushUserInfo`; removed: D12597: [lib] Fix construction of `ThinRawThreadInfo` in `createPendingThread`.Mon, Jul 15, 11:31 AM

atul added a child revision: D12755: [lib] Add `flow` suppression to `deprecatedMinimallyEncodeRawThreadInfo`.Mon, Jul 15, 11:38 AM

First: is rawThreadInfoFromServerThreadInfo just for the shimming logic that handles old clients?

Yes, so we can construct RawThreadInfo with member permissions for clients that still expect them. We will construct "new" RawThreadInfos by stripping out member permissions using same utility function that'll be used in client migrations.