We have a single sandbox environment where all of our schema changes are made, and when the changes are finalized, we run a migration against an environment forked from our most recent primary and then promote the result (we never manually change the schema in the primary environment itself, so every model and field created there is the result of a migration).
For the most part the autogenerated migrations have been working well, and the generated diffs have been clean. Recently though we added a field (type SEO) to each of two models we have in our sandbox environment via the dashboard. We autogenerated and ran a migration for this, but this time, the resulting fields in the primary environment were created with different IDs compared to their source fields. I’ve noticed that previous fields created in primary as a result of migrations so far have pretty consistently maintained the source IDs from the sandbox. Not sure if this difference is related to the problem that I am seeing, but figured I mentioned it in case.
The problem itself is that any autogeneration of migrations we’ve done since has resulted in a migration file that tries to recreate those same two fields again. It doesn’t seem to detect that they already exist. I attempted to wipe the slate clean by deleting them in the sandbox environment, and creating and running a migration to wipe them from the primary too. But even with the fields gone from both environments, starting from scratch (creating the fields in our sandbox environment again via the dashboard, autogenerating a migration and running it) still results in fields that are out-of-sync between the two environments.
The generated migrations naturally fail when left as-is and result in uniqueness errors. Here is a snippet from a migration I just auto-generated:
console.log("Creating new fields/fieldsets");
console.log(
'Create SEO meta tags field "SEO" (`seo`) in model "Report" (`report`)',
);
newFields["10511396"] = await client.fields.create("1692991", {
label: "SEO",
field_type: "seo",
api_key: "seo",
appearance: { addons: [], editor: "seo", parameters: {} },
});
console.log(
'Create SEO meta tags field "SEO" (`seo`) in model "Article" (`article`)',
);
newFields["10511395"] = await client.fields.create("1702627", {
label: "SEO",
field_type: "seo",
api_key: "seo",
appearance: { addons: [], editor: "seo", parameters: {} },
});
console.log("Destroy fields in existing models/block models");
console.log(
'Delete SEO meta tags field "SEO" (`seo`) in model "Report" (`report`)',
);
await client.fields.destroy("10565112");
console.log(
'Delete SEO meta tags field "SEO" (`seo`) in model "Article" (`article`)',
);
await client.fields.destroy("10565113");
console.log("Update existing fields/fieldsets");
console.log(
'Update SEO meta tags field "SEO" (`seo`) in model "Report" (`report`)',
);
await client.fields.update(newFields["10511396"], { position: 6 });
console.log(
'Update Structured text field "Body" (`body`) in model "Report" (`report`)',
);
await client.fields.update("8779520", { position: 5 });
console.log(
'Update SEO meta tags field "SEO" (`seo`) in model "Article" (`article`)',
);
await client.fields.update(newFields["10511395"], { position: 7 });
It first tries to create the fields again (which fails on running because they exist already – uniqueness error) and interestingly tries to delete the old (?) fields afterward. I don’t see how that order could ever make sense – so I’m inclined to think there must be a bug here. Any idea what could be wrong? How can I fix the environments so we don’t have these fields out of sync?