if a dev is introducing a new migration how will they know which migrationType variant to use? can we instead introduce an optional field in Migration to override the default behavior?

In D13209#372882, @varun wrote:

if a dev is introducing a new migration how will they know which migrationType variant to use? can we instead introduce an optional field in Migration to override the default behavior?

We could make wrap_in_transaction_and_block_requests the default behavior.

Was wondering if you think this is better suited as a boolean. Originally had this is as string union but liked the explicative naming of these types, allowing us to possibly introduce new migrationTypes later as well (but unsure how likely this is).

In D13209#373102, @will wrote:

In D13209#372882, @varun wrote:

if a dev is introducing a new migration how will they know which migrationType variant to use? can we instead introduce an optional field in Migration to override the default behavior?

We could make wrap_in_transaction_and_block_requests the default behavior.

Was wondering if you think this is better suited as a boolean. Originally had this is as string union but liked the explicative naming of these types, allowing us to possibly introduce new migrationTypes later as well (but unsure how likely this is).

I think you can keep MigrationType as-is and just change Migration:

export type Migration = {
  +version: number,
  +migrationPromise: () => Promise<mixed>,
  +migrationType?: MigrationType,
};

then in the logic where you check the migrationType, just treat "wrap in transaction" as the default behavior if the field is missing