Group replication failures and recovery

Hello everyone,
I have two questions related to Group Replication version 8.0.33-25, (percona) and I believe they might be of interest.
The group_replication_recovery channel switched from 4 active worker threads to only two without any error messages or warnings. Can anyone suggest why this might have happened? The server has a 24-hour backlog, and although it’s progressing relatively quickly, I’m curious about the underlying issue. Any insights?
Running script alter table … add partition…, to add ~500 partititons to one empty! table. Ran it on one node, let the replication to do the work on another nodes.
On two nodes working like charm , on thrid node failed after ~200 partitions. When running failed trx manually working. I’ve resolved it by skipping all ~300 trx that remain and by adding all these manually (with bin log off for the session), but still very curious what it was and why it happen.
The table in question:
CREATE TABLE pf (
id int unsigned NOT NULL AUTO_INCREMENT,
date1 timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP,
id2 int unsigned NOT NULL DEFAULT ‘0’,
id3 smallint unsigned NOT NULL DEFAULT ‘0’,
date2 timestamp NOT NULL,
PRIMARY KEY (id,id1),
) ENGINE=InnoDBDEFAULT CHARSET=latin1
PARTITION BY RANGE (id1)
The error was:
[ERROR] [MY-010584] [Repl] Replica SQL for channel ‘group_replication_applier’: Worker 1 failed executing transaction ‘805647e2-531c-11ee-b0d2-6805caf1445a:3398599’; Error ‘Invalid default value for ‘date’’ on query. Default database: ‘XXX’. Query: ‘alter table XXX.pf add partition (partition p_150200000 values less than (150200000))’, Error_code: MY-001067
Many thanks.

Is this the full create table statement?
I don’t see a date column where it errors out.
Can you also past output of select @@sql_mode from all hosts along with full create table statement

Sorry,
I misspelled the column name. It should be ‘date’ (as in the current CREATE TABLE statement that I posted), so the error is relevant. The SQL_MODE is identical on all three replica servers (they are identical). Also, if the issue is related to SQL_MODE, how did the other two nodes successfully complete the script? How did the ‘failing’ node complete the first ~200 ALTER TABLE statements?
sql_mode:

+-------------------------------------------------------------------------------------------+
| @@sql_mode                                                                                |
+-------------------------------------------------------------------------------------------+
| STRICT_TRANS_TABLES,ALLOW_INVALID_DATES,ERROR_FOR_DIVISION_BY_ZERO,NO_ENGINE_SUBSTITUTION |
+-------------------------------------------------------------------------------------------+

Thank you very much

Just noticed,
I misspelled the column name I partitioned by, perhpas it id2.

Thanks