The index for that fk should have been created in migration v59.2026-01-31T12:00:39. Check that the index exists. Also check the log if there was an exception, or if that one got marked MARK_RAN due to a precondition failure.
If it’s not there you could create it using this command, but then we have to figure out why it isn’t there and if anything else is missing.
CREATE UNIQUE INDEX idx_workspace_transform_workspace_global_unique ON workspace_transform (workspace_id, global_id)
You can use this MySQL command to view the indexes on the workspace_transform table:
SHOW INDEXES ON TABLE workspace_transform;
The output from an app database for v59.4 that the migrations ran successfully on (sorry, wide):
Thanks for helping out.
This index was existing, so that wasn’t the problem.
After some debugging / looking at the changelogs etc. We figured out that we had an existing primary key in the table workspace_transform.
MySQL 8.0+ is automatically creating a PK with a invisible column, if there isn’t one existing (at least for us when hosted in azure).
So we had to executed: ALTER TABLE workspace_transform DROP COLUMN my_row_id, ADD CONSTRAINT pk_workspace_transform PRIMARY KEY (workspace_id, ref_id);
That seems to solve the problem - v59 is now running