Change Details

Similar to what we did in D10283, we're "lying" to `flow` and saying that `updatedRolesAndPermissions` (which we also rename `legacyUpdateRolesAndPermissions`) accepts `RawThreadInfos` instead of just `LegacyRawThreadInfos`. However, we call `assertAllThreadInfosAreLegacy` right at the start of `legacyUpdateRolesAndPermissions` to ensure that only `LegacyRawThreadInfos` are passed to this function. It could be argued that this is worse than D10283, because it's unlikely that we'd want to run the `convertThreadStoreThreadInfosToNewIDSchema` migration again, whereas it's VERY likely that we'll want to run `updateRolesAndPermissions` in the future. I will introduce a new version of `updateRolesAndPermissions` that'll handle `MinimallyEncodedRawThreadInfos` (by going through and converting all to `LegacyRawThreadInfos` which is what the logic in this migration requires since that's what eg `getRolePermissionBlobs` and `makePermissionsBlob` deal with. I'll put that up as a followup diff in this stack (probably before landing anything). However, as of this diff we're not at 0 `flow` issues in `native`/`web`/`keyserver`/`lib`. --- Depends on D10283

Similar to what we did in D10283, we're "lying" to `flow` and saying that `updatedRolesAndPermissions` (which we also rename `legacyUpdateRolesAndPermissions`) accepts `RawThreadInfos` instead of just `LegacyRawThreadInfos`. However, we call `assertAllThreadInfosAreLegacy` right at the start of `legacyUpdateRolesAndPermissions` to ensure that only `LegacyRawThreadInfos` are passed to this function. It could be argued that this is worse than D10283, because it's unlikely that we'd want to run the `convertThreadStoreThreadInfosToNewIDSchema` migration again, whereas it's VERY likely that we'll want to run `updateRolesAndPermissions` in the future. I will introduce a new version of `updateRolesAndPermissions` that'll handle `MinimallyEncodedRawThreadInfos` (by going through and converting all to `LegacyRawThreadInfos` which is what the logic in this migration requires since that's what eg `getRolePermissionBlobs` and `makePermissionsBlob` deal with. I'll put that up as a followup diff in this stack (probably before landing anything). However, as of this diff we're now at 0 `flow` issues in `native`/`web`/`keyserver`/`lib`. --- Depends on D10283

Similar to what we did in D10283, we're "lying" to `flow` and saying that `updatedRolesAndPermissions` (which we also rename `legacyUpdateRolesAndPermissions`) accepts `RawThreadInfos` instead of just `LegacyRawThreadInfos`. However, we call `assertAllThreadInfosAreLegacy` right at the start of `legacyUpdateRolesAndPermissions` to ensure that only `LegacyRawThreadInfos` are passed to this function. It could be argued that this is worse than D10283, because it's unlikely that we'd want to run the `convertThreadStoreThreadInfosToNewIDSchema` migration again, whereas it's VERY likely that we'll want to run `updateRolesAndPermissions` in the future. I will introduce a new version of `updateRolesAndPermissions` that'll handle `MinimallyEncodedRawThreadInfos` (by going through and converting all to `LegacyRawThreadInfos` which is what the logic in this migration requires since that's what eg `getRolePermissionBlobs` and `makePermissionsBlob` deal with. I'll put that up as a followup diff in this stack (probably before landing anything). However, as of this diff we're notnow at 0 `flow` issues in `native`/`web`/`keyserver`/`lib`. --- Depends on D10283