Bug #119996 Row delete from a table with selfreferental FK breaks replication

Description:
If a table has a FK that is referencing the same table, deleting a row breaks the replication (error on the replica, the replica stops)

Most probably, this is the regression caused by commit 9e1e77fa (WL#11249 - Support Foreign Key Cascading Operation in server). Bug is not present in 9.5

How to repeat:
Two nodes: primary -> async replication -> replica

On primary execute:
CREATE TABLE t1 (
    f1 INT NOT NULL PRIMARY KEY,
    f2 INT,
    FOREIGN KEY (f2)
        REFERENCES t1(f1)
        ON DELETE CASCADE
) ENGINE=InnoDB;

INSERT INTO t1 VALUES (1, 1), (2, 1);

DELETE FROM t1 WHERE f1 = 1;

The result on replica:
2026-03-06T09:45:00.907942Z 11 [ERROR] [MY-010584] [Repl] Replica SQL for channel '': Worker 1 failed executing transaction '9b25c286-193f-11f1-8052-c84bd64e0288:6' at source log binlog.000001, end_log_pos 1750; Could not execute Delete_rows event on table test.t1; Can't find record in 't1', Error_code: 1032; handler error HA_ERR_KEY_NOT_FOUND; the event's source log binlog.000001, end_log_pos 1750, Error_code: MY-001032
2026-03-06T09:45:56.928104Z 10 [Warning] [MY-010584] [Repl] Replica SQL for channel '': ... The replica coordinator and worker threads are stopped, possibly leaving data in inconsistent state. A restart should restore consistency automatically, although using non-transactional storage for data or info tables or DDL queries could lead to problems. In such cases you have to examine your data (see documentation for details). Error_code: MY-001756

Posted by developer: Bug status updated to 'Documenting'

Posted by developer:
 
Added the following note to the MySQL Server 9.7.2 and 26.7.0 release notes:

Deleting a row from a table with a self-referencing foreign key caused replication to fail.