FLUSH CHANGED_PAGE_BITMAPS leaves gaps between the last written bitmap LSN and InnoDB checkpoint LSN

I am sorry, I got it backwards, of course it makes sense

There is a comment in log0recv.cc:

I read it as redo log apply starts with the checkpoint LSN or if checkpoint LSN points to the middle of the log record, then with the first log record past checkpoint LSN.

What the code actually does, it starts to parse redo log from within the same log block as checkpoint_lsn points to. This is done because checkpoint_lsn may point to the middle of the log record. It however remembers the bytes_to_ignore_before_checkpoint as the number of bytes to ignore between parse_start_lsn and checkpoint_lsn. So, it seems it does exactly what advertised and log records are indeed applied starting with checkpoint LSN or at some point after checkpoint LSN.

Anyways, it is guaranteed that redo log application is started from the log block containing the checkpoint LSN. What I see with current changed page tracking is that tracked LSN is ~9k bytes behind the checkpoint LSN which is ~17 log blocks. (I run large inserts with log record size from 8k to 16k)

How can crash recovery apply record whose tail falls after checkpoint lsn? By definition it's not a persisted one?

Crash recovery starts to apply log records from the point at checkpoint lsn or after checkpoint lsn. So, we need to track everything at least up to checkpoint lsn (it is fine if we track more). If we tracked less, backup will be invalid.
Suggested fix is to remember the checkpoint LSN at the beginning of FLUSH command. This LSN will be equal or greater than the one xtrabackup started to copy redo logs from. Then run log_online_follow_redo_log possibly several times until log_bmp_sys->parse_buf.get_current_lsn() becomes greater or equal to the saved LSN. Then we consider that FLUSH is done.

Is that an actual issue and not something forced by design? InnoDB crash recovery know operates under the same constraint, it might find a truncated log record right at the checkpoint boundary, hence effectively the last log record is one before.

What would be the fix?