1. Can you annotate every any-cast with an explanation as to why it is needed? Please include the Flow error you're seeing, and the other things you've tried. Going forward, please always include this when using an any-cast (or something comparable, like Object or Function or $FlowFixMe)
2. I worry that the codegenned file might get out of sync with its inputs. Before landing, can you create a Linear task to add a CI job that regenerates the file and confirms there are no changes? We should make sure we complete that task before we ship this project.

In D8355#246571, @ashoat wrote:

2. I worry that the codegenned file might get out of sync with its inputs. Before landing, can you create a Linear task to add a CI job that regenerates the file and confirms there are no changes? We should make sure we complete that task before we ship this project.

Might be helpful to take a look at the JSI codegen CI approach:

cd native && yarn codegen-jsi && git diff --exit-code

where git diff --exit-code will return nonzero exit code if there are any changes in working copy and fail the CI job.

In D8355#246571, @ashoat wrote:

2. I worry that the codegenned file might get out of sync with its inputs. Before landing, can you create a Linear task to add a CI job that regenerates the file and confirms there are no changes? We should make sure we complete that task before we ship this project.

Do you mean that it will desync before getting released or later? Because they not being synchronized, is the reason why we are generating static functions and not using validators directly. If at some point in the future, we update the validators we don't want to also update these functions because the migration code shouldn't change. So the CI job would have to be removed after shipping anyway.

This needs a very close review on the types. It looks pretty daunting, and I don't have time for this tonight unfortunately. Hopefully I will have some time tomorrow, but we'll see.

It would be a lot easier if you had done as requested and annotated each any type individually with an explanation for why it's necessary, as well as the error you're seeing. Ideally in a code comment. The easier you make to review for your reviewers, the sooner you'll be able to land it, and the less frustrating you'll make our experience

Do you mean that it will desync before getting released or later? Because they not being synchronized, is the reason why we are generating static functions and not using validators directly. If at some point in the future, we update the validators we don't want to also update these functions because the migration code shouldn't change. So the CI job would have to be removed after shipping anyway.

Makes sense

I've also checked the converted db with the validators:

const { messages, threads, messageStoreThreads } =
        await commCoreModule.getClientDBStore();

      const rawMessageInfos = messages.map(
        translateClientDBMessageInfoToRawMessageInfo,
      );

      convertClientIDsToServerIDs(
        '256',
        t.list(rawMessageInfoValidator),
        rawMessageInfos,
      );

      const rawThreadInfos = threads.map(
        convertClientDBThreadInfoToRawThreadInfo,
      );

      convertClientIDsToServerIDs(
        '256',
        t.list(rawThreadInfoValidator),
        rawThreadInfos,
      );

      const rawMessageStoreThreadInfos =
        translateClientDBThreadMessageInfos(messageStoreThreads);

      if (
        Object.keys(rawMessageStoreThreadInfos).some(
          threadID => !threadID.startsWith('256|'),
        )
      ) {
        console.log('INVALID');
      }

      console.log('done');

• before migration: I got invalid_client_id_prefix error (because the ids weren't migrated)
• after migration: no errors

Yeah, use of this any is contastrained to this one specific migration, and it's used as a function passed to other functions (that are typed correctly) so it shouldn't 'infect' other code