Migration generation order is wrong when using existing fields

[ldc]

Since I don’t have a small reproduce case, I’m going to do my best here to describe the bug we encountered.

• Fork environment staging to staging-fork
• Make changes in staging-fork:
  • Manually delete a field (e.g. title)
  • re-create a field with the same api_key: title
• Generate a migration
  npx datocms migrations:new 'update-title' --autogenerate=staging-fork:staging
• Apply the migration
• Migration fails

The reason that it fails, is that the create statement of api_key title happens before the destroys.
We get a block of create migrations, then a block of destroys and finally a block of updates.
However, in this case, the existing field title should be destroyed before we re-create it.

Solved our issue by manually moving the destroy functions to the top of the migration file.

[roger]

Hi @ldc,

I believe this is the same issue (or perhaps an expanded explanation?) as the other post, right? Bug: Autogenerating and running migrations tries to generate schema_migration model twice - #7 by roger

We noticed the same thing as you there, and have filed a bug report about it. It is currently awaiting developer investigation, and I’ll let you know once we have any new findings.

If these are indeed the same issue, is it OK with you if I merge the two threads? Or if I misunderstood and this is a different scenario, please let me know.

Thank you again for your report and patience with this! Sorry for the inconvenience.

[ldc]

I think this one is different.
If my hunches & assumptions are correct:

• The other thread incorrectly generates code to create a schema_migration, maybe because of the schema_migration model having different record IDs on different environments.
• This thread generates migration code in the wrong order, in the case of deleting a field and re-creating it.

[ldc]

Found another issue related to migrations & plugins.

Generated migration code:

  console.log('Delete plugin "Read-only Fields"');
  await client.plugins.destroy('bNeGi2IHRaCsAQQyZPB76g');

  console.log('Install plugin "Read-only Fields"');
  await client.plugins.create({
    id: 'mbq9DrdzRIGqrmwwWJztEg',
    package_name: 'datocms-plugin-readonly-fields',
  });
  await client.plugins.update('mbq9DrdzRIGqrmwwWJztEg', { parameters: { developmentMode: false } });

2 issues in fact:

• Getting an unexpected validation error for the developmentMode flag

[
  {
    "id": "306dbb",
    "type": "api_error",
    "attributes": {
      "code": "INVALID_FIELD",
      "details": {
        "field": "parameters.developmentMode",
        "code": "VALIDATION_REQUIRED"
      }
    }
  }
]

The generated migration code should set the flags correctly.

• The first destroy of the existing plugin fails, because it’s used by some fields.
  e.g. if I’d try to click-delete it, I get an error
  
  

Executing the migration, the script simply continues after the failed delete.
It doesn’t check if delete was successful and we end up with the same plugin twice.

Should I move this to a separate thread?

The cause is actually related to Bug: Autogenerating and running migrations tries to generate schema_migration model twice - #9 by ldc
but the unintended behavior seems to show 2 unrelated bugs.

[roger]

Thank you for the additional reports, @ldc! We have a developer currently investigating these, and I’ll attach this to the report as well.

I’ll update you once we have a resolution. Sorry about that!