Page MenuHomePhabricator

[lib] Deprecate `decodeMinimallyEncodedRawThreadInfo`
ClosedPublic

Authored by atul on Jun 27 2024, 1:44 PM.
Tags
None
Referenced Files
Unknown Object (File)
Mon, Nov 11, 6:10 PM
Unknown Object (File)
Mon, Nov 11, 10:27 AM
Unknown Object (File)
Mon, Nov 11, 8:24 AM
Unknown Object (File)
Mon, Nov 11, 6:28 AM
Unknown Object (File)
Mon, Nov 11, 2:45 AM
Unknown Object (File)
Mon, Nov 11, 1:44 AM
Unknown Object (File)
Oct 11 2024, 2:16 AM
Unknown Object (File)
Oct 11 2024, 2:16 AM
Subscribers

Details

Summary

This function is used in 3 places:

  1. Unit tests
  2. updateRolesAndPermissions
  3. deprecatedConvertClientDBThreadInfoToRawThreadInfo

We will deprecate updateRolesAndPermissions in subsequent diff in this stack, at which point this function will only be relevant for keeping existing "legacy" migrations functional. It will not and should NOT be used for migrations going forward because there are no encoded member permissions to be decoded in future persisted *RawThreadInfo.


Depends on D12597

Test Plan

This diff is just a rename, will add flow suppression in next diff. Looked at all callsites and made sure there's nothing preventing function from being deprecated.

Diff Detail

Repository
rCOMM Comm
Lint
Lint Not Applicable
Unit
Tests Not Applicable

Event Timeline

atul published this revision for review.Jun 27 2024, 1:45 PM

Is the idea here that we'll never need to decode the permissions on RawThreadInfo again, since we don't store the permissions on the client?

How about all the other decode* and encode* functions – should those be marked as deprecated as well?

This revision is now accepted and ready to land.Jul 1 2024, 1:02 PM

Is the idea here that we'll never need to decode the permissions on RawThreadInfo again, since we don't store the permissions on the client?

It's possible we may want to decode RawThreadInfos in the future, but we can re-introduce a new utility at that point that handles roles and currentUser and skips members which won't have stored permissions.

How about all the other decode* and encode* functions – should those be marked as deprecated as well?

Motivation for deprecating these was flow-related, specifically the change to the *RawThreadInfo type. There's no immediate need to deprecate the others.

Safe to land out of order since it's purely rename

This revision was landed with ongoing or failed builds.Jul 9 2024, 12:29 PM
This revision was automatically updated to reflect the committed changes.