There already is a test for which we fail to notice corruption:

./mtr encryption.innodb-force-corruption

It will issue messages about 2 tables to the error log, but not about this one:

CREATE TABLE t3 (a INT AUTO_INCREMENT PRIMARY KEY, b TEXT, c char(200)) ENGINE=InnoDB page_compressed=yes encrypted=yes;

Before the follow-up fix to MDEV-12112, no messages were emitted about any of these 3 tables to the error log.

While fixing this, I would suggest fixing the page trailer validation further: if the page trailer is supposed to contain the least significant bits of FIL_PAGE_LSN but fails to do so, then the page should be rejected as invalid.

With the fix, mariabackup is validating each page with buf_page_is_corrupted(). Thanks to that, we should be validating that the LSN at the start and end of the page match. (The end LSN is not present in ROW_FORMAT=COMPRESSED, which is not to be confused with page_compressed=1.)

In MDEV-13103, I made a mistake in the error handling of page_compressed=1 decryption when the default innodb_compression_algorithm=zlib is used. Due to this mistake, with certain versions of zlib, MariaDB would fail to detect a corrupted page.

The problem was uncovered by the tests mariabackup.unencrypted_page_compressed and mariabackup.encrypted_page_compressed that were added as part of this work. It appeared to occur with older zlib only.

With the follow-up fixes, this ticket not only implemented the consistency checks that were missing in mariabackup, but also improved the handling of corrupted page_compressed pages in the MariaDB server.