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). 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). 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