Table cannot be backed up after a innodb import tablespace for tables without foreign key

Hi there,

I am currently making a mariabackup script for full and incremental backups along with a prepare script to loop through the compressed incrementals and apply to the full. I am also making a script to automate the process for a single DB restore from a full mariabackup. I came up with the scripts needed to make it easier for this blog post from 2018 which can be found here, my SQL script can be found here and the order you run them to take the full backup and restore a single Database.

The issue I have came across is after I generate the .cfg files from the full backup and then restore a single DB with my bash script which does so just fine. When I run my backup script again and prepare the backup with the new incremental the .ibd and .cfg files aren't generated for tables that didn't have a foreign key on them. I have tested this to make sure by running the above process by restoring from a older backup, adding a foreign key to the table, running the same process. I found that the newly added foreign key makes it so the new backup can generate the .ibd and .cfg files so the table isn't corrupted after innodb import statement. The only tables corrupted are the ones without foreign keys I have tried running FLUSH TABLES and FLUSH TABLES .. FOR EXPORT with no luck in sorting this.

Also, I first tried this on 10.6.15 then upgraded to 10.11.5 so this bug is there for all versions.

I have also tried restarted mariadb after the import then ran a backup with no luck, after I run a backup (incremental) then do a full restore from this incremental applied to the fullbackup it says the table isn't registered in the InnoDB engine.

In the screenshot attached you should be able to see that at the vip table (prepared with incremental, backup before innodb import) and at the bottom the same table (after importing innodb tables, after running a backup and preparing the backup with --export for .cfg files)

Nothing in the prepare logs say anything to suggest the backup is broken or the .cfg cannot be generated