Change Details

`createUpdateDBOpsForThreadStoreThreadInfos` consumes `deprecatedConvertClientDBThreadInfoToRawThreadInfo`, but based on the name `createUpdateDBOpsForThreadStoreThreadInfos` it's not clear that the function is only for handling "Legacy" `RawThreadInfo`s. I should've made this more clear when I was doing the refactoring work. We **could** modify these functions to handle both (previously known as) `LegacyRawThreadInfo`s and `MinimallyEncodedRawThreadInfo`s, but that would complicate the logic and make things tricky with `flow` types (because we want to support Legacy -> Legacy, Legacy -> MinimallyEncoded, and MinimallyEncoded -> MinimallyEncoded migration functions). It would also be good to keep these existing utilities "frozen" so we don't have to go back and test old migrations pre-minimalEncoding... which would be tedious and time consuming. Personally think it makes sense to keep these utilities "frozen" in a `deprecated-*` file and introduce new functions that only handle `MinimallyEncoded->MinimallyEncoded` going forward. This is kind of an opinionated decision, so adding @ashoat as reviewer to get his thoughts. --- Depends on D11056

`createUpdateDBOpsForThreadStoreThreadInfos` consumes `deprecatedConvertClientDBThreadInfoToRawThreadInfo`, but based on the name `createUpdateDBOpsForThreadStoreThreadInfos` it's not clear that the function is only for handling "Legacy" `RawThreadInfo`s. I should've made this more clear when I was doing the refactoring work. We **could** modify these functions to handle both (previously known as) `LegacyRawThreadInfo`s and `MinimallyEncodedRawThreadInfo`s, but that would complicate the logic and make things tricky with `flow` types because we want to support Legacy -> Legacy, Legacy -> MinimallyEncoded, and MinimallyEncoded -> MinimallyEncoded migration functions. Whereas in the future we only care about `MinimallyEncoded` -> `MinimallyEncoded` migrations and the legacy stuff just adds clutter. It would also be good to keep these existing utilities "frozen" so we don't have to go back and test old migrations pre-minimalEncoding... which would be tedious and time consuming. Personally think it makes sense to keep these utilities "frozen" in a `deprecated-*` file and introduce new functions that only handle `MinimallyEncoded->MinimallyEncoded` going forward. This is kind of an opinionated decision, so adding @ashoat as reviewer to get his thoughts. --- Depends on D11056

`createUpdateDBOpsForThreadStoreThreadInfos` consumes `deprecatedConvertClientDBThreadInfoToRawThreadInfo`, but based on the name `createUpdateDBOpsForThreadStoreThreadInfos` it's not clear that the function is only for handling "Legacy" `RawThreadInfo`s. I should've made this more clear when I was doing the refactoring work. We **could** modify these functions to handle both (previously known as) `LegacyRawThreadInfo`s and `MinimallyEncodedRawThreadInfo`s, but that would complicate the logic and make things tricky with `flow` types (because we want to support Legacy -> Legacy, Legacy -> MinimallyEncoded, and MinimallyEncoded -> MinimallyEncoded migration functions. and MinimallyEncoded -> MinimallyEncoded migration functions)Whereas in the future we only care about `MinimallyEncoded` -> `MinimallyEncoded` migrations and the legacy stuff just adds clutter. It would also be good to keep these existing utilities "frozen" so we don't have to go back and test old migrations pre-minimalEncoding... which would be tedious and time consuming. Personally think it makes sense to keep these utilities "frozen" in a `deprecated-*` file and introduce new functions that only handle `MinimallyEncoded->MinimallyEncoded` going forward. This is kind of an opinionated decision, so adding @ashoat as reviewer to get his thoughts. --- Depends on D11056