Page MenuHomePhabricator

[lib] Change return type of `minimallyEncodeRawThreadInfo` to `RawThreadInfoWithMemberPermissions`
AbandonedPublic

Authored by atul on Jun 24 2024, 3:31 PM.
Tags
None
Referenced Files
Unknown Object (File)
Thu, Dec 19, 7:02 AM
Unknown Object (File)
Thu, Dec 19, 7:02 AM
Unknown Object (File)
Thu, Dec 19, 7:02 AM
Unknown Object (File)
Fri, Dec 13, 10:15 PM
Unknown Object (File)
Fri, Dec 6, 12:42 AM
Unknown Object (File)
Fri, Dec 6, 12:18 AM
Unknown Object (File)
Nov 1 2024, 3:00 PM
Unknown Object (File)
Oct 23 2024, 7:22 PM
Subscribers
None

Details

Summary

Introduce RawThreadInfoWithMemberPermissions which will be used for "legacy" migrations + on keyserver to handle old clients + old validator.

minimallyEncodeRawThreadInfo will encode permissions and return RawThreadInfoWithMemberPermissions. Will be used along with stripPermissionsFromMemberInfo on new clients + on keyserver to handle new clients.

NOTE: This diff "introduces flow issues to resolve a flow issue. Diffs after this in stack will be about resolving minimallyEncodeRawThreadInfo-related issues.

Depends on D12556

Test Plan

flow

Diff Detail

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

Event Timeline

Harbormaster returned this revision to the author for changes because remote builds failed.Jun 24 2024, 3:44 PM
Harbormaster failed remote builds in B29903: Diff 41662!
atul requested review of this revision.Jun 25 2024, 9:41 AM
IMPORTANT: Even if there aren't any flow issues here, will need to be extra careful with changes to minimallyEncodeRawThreadInfo/minimallyDecodeRawThreadInfo to make sure things work correctly with previous persisted representation of data to avoid breaking things. That was the issue with the "dropping isDefault" migration.
IMPORTANT: We also may want to introduce a deprecated* variant of this function to ensure old migrations continue working even though we may not get flow issues.

Abandoning in favor of stack starting with D12594 because lots of things have changed and there's not really 1:1 correspondence with old stack and new stack so I don't think it makes sense to update in place, change a bunch of child/parent diff relationships, etc.