MySQL Bugs: #120304: MySQL 8.0.44 crashes with InnoDB assertion failure on replica when TRUNCATE TABLE is applied to a table whose tablespace

Bug #120304	MySQL 8.0.44 crashes with InnoDB assertion failure on replica when TRUNCATE TABLE is applied to a table whose tablespace
Submitted:	20 Apr 22:05	Modified:	22 Apr 21:18
Reporter:	zyshe kolodny	Email Updates:
Status:	Open	Impact on me:	None
Category:	MySQL Server: InnoDB storage engine	Severity:	S1 (Critical)
Version:	8.0.44	OS:	CentOS (07)
Assigned to:		CPU Architecture:	x86 (x86_64)
Tags:	assertion, crash, innodb, replica, replication, tablespace-missing, truncate

Description:
MySQL 8.0.44 crashes with an InnoDB assertion failure when a replica applies TRUNCATE TABLE asteriskcdrdb.cel and the target table is already in a missing-tablespace state.

Before the crash, the replica had already reported MY-001812: Tablespace is missing for table asteriskcdrdb.cel while applying normal DML (INSERT INTO cel ...). This indicates that the table was already broken before TRUNCATE was attempted.

Instead of returning a normal error for the TRUNCATE TABLE statement, the server aborts with signal 6 and the following assertion:

Assertion failure: ha_innodb.cc:11477: strlen(m_remote_path) != 0

Relevant stack frames include innobase_truncate::truncate, ha_innobase::truncate_impl, and Sql_cmd_truncate_table::execute. The crash occurs in the replica SQL applier path.

This appears to be a server bug in InnoDB DDL handling for a table with a missing tablespace. Even if the table is already corrupted or inconsistent, MySQL should report an error and keep running; it should not terminate the server process.

How to repeat:
Configure MySQL 8.0.44 replication with an InnoDB table on the replica.
Cause the replica-side table to enter a missing-tablespace state, for example so that operations against it return MY-001812 Tablespace is missing.
Confirm the replica SQL thread reports an error for DML against that table, such as:
Error 'Tablespace is missing for table asteriskcdrdb.cel'
Apply or execute:
TRUNCATE TABLE asteriskcdrdb.cel;
Observe that mysqld aborts with signal 6 instead of returning a normal SQL error.

Observed error log excerpt:

Assertion failure: ha_innodb.cc:11477: strlen(m_remote_path) != 0
stack includes innobase_truncate::truncate
query shown in crash output: TRUNCATE TABLE asteriskcdrdb.cel

Suggested fix:
In the InnoDB truncate / table-create path, handle missing or invalid tablespace path state defensively and return a proper SQL error instead of asserting and aborting the server.

Specifically, when the table is already known to be in a missing-tablespace state (MY-001812), TRUNCATE TABLE should fail gracefully with an error comparable to the missing-tablespace condition, without crashing mysqld.

Looks related to the symlink problem I blogged about in below.

https://jfg-mysql.blogspot.com/2026/04/symlinks-are-unsafe-in-mysql.html

See also Bug#119554 and Bug#117660.

indeed there a permanent symlink 
what should be done about ?

> what should be done about ?

Some solutions in the blog.  Or it looks like this is fixed in 8.0.46.

(note that I am not MySQL Support Team, I am a Community Member trying to be helpful, you can contact me via https://linktr.ee/jfg.mysql)