The issue starts happening as soon as the table is created. This may prove not to be a bug, however even in that case the error is unclear in the error log (i.e. it would be hard for any DBA to discover what the cause was especially if multiple events were scheduled). If not a bug, then this can be a feature request to add the failing query to the error message.

The reason it may be a bug however is that when the INSERT statement is executed manually at the command line (after creating a table with two columns and with a similar setup), the issue does not happen (or is not reported given that the event scheduler is not active in that case, though no other error is reported either).

# mysqld options required for replay: --log-bin

SET GLOBAL binlog_format=STATEMENT,GLOBAL event_scheduler=1;

CREATE EVENT e ON SCHEDULE EVERY 1 SECOND DO INSERT INTO t VALUES (1);

SET GLOBAL TRANSACTION ISOLATION LEVEL READ COMMITTED;

CREATE TABLE t (c INT);

Leads to:

2021-07-28 19:49:57 6105 [ERROR] Event Scheduler: [root@localhost][test.e] Got error 170 "It is not possible to log this statement" from storage engine InnoDB

Yet,

# mysqld options required for replay: --log-bin

SET GLOBAL binlog_format=STATEMENT,GLOBAL event_scheduler=1;

SET GLOBAL TRANSACTION ISOLATION LEVEL READ COMMITTED;

CREATE TABLE t (c INT);

INSERT INTO t VALUES (1);

Produces no such issue. This is somewhat expected as the error is reported by the event scheduler in the first case. However, no other error is produced either, thus; either the statement should be loggable (alike to the second example) or an error needs to be produced in this case also (alike to the first example) - and in such case the error can be improved by adding the failing-to-be-logged query to it.