Specifically, the command mariabackup --prepare --export is supposed to purge the history of old transactions, and also apply all logs.
MDEV-25180, InnoDB no longer treats specially any tables whose names start with #sql. The only exception are table names that start with #sql-ib. It is the responsibility of the SQL layer's DDL log recovery to drop any such tables, in case the server was killed (or a backup was made) while a table-rebuilding DDL operation was in progress.
The following patch proves that a regression was introduced. If the function (which would start the InnoDB purge of transaction history) would be invoked during mariabackup --prepare --export, the execution would be aborted due to assertion failure.
We must ensure that ha_signal_ddl_recovery_done() will be invoked. Should it for some reason be unacceptable to invoke ddl_log_execute_recovery() in mariabackup --prepare --export, then we would have to invoke special code that would drop all #sql- tables from InnoDB, before executing ha_signal_ddl_recovery_done(). In any case, we must somehow compensate for the change that was made in
Note: Nothing must change in mariabackup outside --prepare --export. We do not want to ruin incremental backups by executing actions that would generate InnoDB redo log records.