fix(core): Add missing primary key to execution annotation tags table

[burivuhster]

Summary

This PR adds missing composite primary index to the table execution_annotation_tags.
It uses typeorm method for MySQL and PostgreSQL, but since sqlite does not support adding primary keys to existing tables, it creates a new table and copy existing data.

Related Linear tickets, Github issues, and Community forum posts

• https://linear.app/n8n/issue/AI-384/community-issue-unable-to-create-or-change-a-table-without-a-primary
• Unable to create or change a table without a primary key on MySQL migration #11123

Review / Merge checklist

• PR title and summary are descriptive. (conventions)
• Docs updated or follow-up ticket created.
• Tests included.
• PR Labeled with release/backport (if the PR is an urgent fix that needs to be backported)

[csuermann]

Since this PR adds another migration on top of the original migration that introduced the table (1724753530828-CreateExecutionAnnotationTables), will this PR actually fix the migration blocker for users that don't have access to the sql_require_primary_key setting in MySQL?

[burivuhster]

@csuermann you are right, adding another migration will not help those who can not disable sql_require_primary_key temporarily. Here is the proposed solution:

1. We edit an initial migration to add PK
2. We also add new migration, which conditionally adds PK if the table does not have it

For the majority of users, who already have the initial migration applied, the new migration will add missing PK.
For those who will install n8n after this PR merged: the table will be created with PK in initial migration, the new migration will have no effect.

What do you think?

[csuermann]

That should solve it! Thanks!

[tomi]

Looks good from my side. I assume you tested both these scenarios:

1. migrating to an empty DB
2. migrating to a DB which has all except the new migration

[tomi]

Do we need to drop these if the tmp table gets dropped at the end? Does that also drop these indexes?

[burivuhster]

Yes, otherwise it fails on creating new table, as indexes with these names are already exist.

[despairblue]

You could give the new indexes custom names to prevent this as well.
I had to do this here as well:

n8n/packages/cli/src/databases/migrations/common/1720101653148-AddConstraintToExecutionMetadata.ts

Lines 83 to 87 in 2e6b03b

	// INFO: The PK names that TypeORM creates are predictable and thus it
	// will create a PK name which already exists in the current
	// execution_metadata table. That's why we have to randomize the PK name
	// here.
	column('id').int.notNull.primaryWithName(nanoid()).autoGenerate,