text:
the container of xenon reports OOM

Describe the problem
the leader of mysql cluster pods reports OOM usually( the log shows the container of xenon reports OOM), even I change the limits from default value 256MiB to 1GiB. The memory usage of the leader may increase  to more than 700M in a few hours.  Why xenon use so much memory?Could it to be limited?
k8s version: v1.23.8
mysql operator version: v2.3.0
mysql version: v8.0.25

which xenon tag do you use ?

这是来自QQ邮箱的假期自动回复邮件。

您好，邮件我已收到，尽快给您回复。

can you paste some log info here? @liarby

can you paste some log info here? @liarby
the screenshot of lens

can you paste some log info here? @liarby

Are there any other logs need  to be provided?

帮忙看一下这个问题，这是OOM故障发生时间点的xenon日志 @acekingke @zhl003
2023-03-12 05:45:01
2023/03/11 21:45:01.644862 api.go:285:    	 [INFO] 	mysql.slave.status:&{ 0  false  false        }
2023-03-12 05:45:01
2023/03/11 21:45:01.645079 api.go:295:    	 [INFO] 	mysql.master.status:&{mysql-bin.000054 678765897  true  true   3795d5b9-ad25-11ed-b9ba-c6bfa851d050:1-535969,
2023-03-12 05:45:01
4daf6505-ad25-11ed-8ade-12b5fa7e697d:1-1310294,
2023-03-12 05:45:01
67d598d1-ad25-11ed-87de-b21adafd20dc:1-7213435 0    }
2023-03-12 05:45:06
2023/03/11 21:45:06.646601 api.go:285:    	 [INFO] 	mysql.slave.status:&{ 0  false  false        }
2023-03-12 05:45:06
2023/03/11 21:45:06.646853 api.go:295:    	 [INFO] 	mysql.master.status:&{mysql-bin.000054 678800611  true  true   3795d5b9-ad25-11ed-b9ba-c6bfa851d050:1-535969,
2023-03-12 05:45:06
4daf6505-ad25-11ed-8ade-12b5fa7e697d:1-1310294,
2023-03-12 05:45:06
67d598d1-ad25-11ed-87de-b21adafd20dc:1-7213501 0    }
2023-03-12 05:45:11
2023/03/11 21:45:11.647639 api.go:285:    	 [INFO] 	mysql.slave.status:&{ 0  false  false        }
2023-03-12 05:45:11
2023/03/11 21:45:11.647878 api.go:295:    	 [INFO] 	mysql.master.status:&{mysql-bin.000054 678834799  true  true   3795d5b9-ad25-11ed-b9ba-c6bfa851d050:1-535969,
2023-03-12 05:45:11
4daf6505-ad25-11ed-8ade-12b5fa7e697d:1-1310294,
2023-03-12 05:45:11
67d598d1-ad25-11ed-87de-b21adafd20dc:1-7213566 0    }
2023-03-12 05:45:16
2023/03/11 21:45:16.644775 api.go:285:    	 [INFO] 	mysql.slave.status:&{ 0  false  false        }
2023-03-12 05:45:16
2023/03/11 21:45:16.645095 api.go:295:    	 [INFO] 	mysql.master.status:&{mysql-bin.000054 678869513  true  true   3795d5b9-ad25-11ed-b9ba-c6bfa851d050:1-535969,
2023-03-12 05:45:16
4daf6505-ad25-11ed-8ade-12b5fa7e697d:1-1310294,
2023-03-12 05:45:16
67d598d1-ad25-11ed-87de-b21adafd20dc:1-7213632 0    }
2023-03-12 05:45:21
2023/03/11 21:45:21.644939 api.go:285:    	 [INFO] 	mysql.slave.status:&{ 0  false  false        }
2023-03-12 05:45:21
2023/03/11 21:45:21.645743 api.go:295:    	 [INFO] 	mysql.master.status:&{mysql-bin.000054 678904227  true  true   3795d5b9-ad25-11ed-b9ba-c6bfa851d050:1-535969,
2023-03-12 05:45:21
4daf6505-ad25-11ed-8ade-12b5fa7e697d:1-1310294,
2023-03-12 05:45:21
67d598d1-ad25-11ed-87de-b21adafd20dc:1-7213698 0    }
2023-03-12 05:45:26
2023/03/11 21:45:26.644754 api.go:285:    	 [INFO] 	mysql.slave.status:&{ 0  false  false        }
2023-03-12 05:45:26
2023/03/11 21:45:26.644959 api.go:295:    	 [INFO] 	mysql.master.status:&{mysql-bin.000054 678938941  true  true   3795d5b9-ad25-11ed-b9ba-c6bfa851d050:1-535969,
2023-03-12 05:45:26
4daf6505-ad25-11ed-8ade-12b5fa7e697d:1-1310294,
2023-03-12 05:45:26
67d598d1-ad25-11ed-87de-b21adafd20dc:1-7213764 0    }
2023-03-12 05:45:31
2023/03/11 21:45:31.644994 api.go:285:    	 [INFO] 	mysql.slave.status:&{ 0  false  false        }
2023-03-12 05:45:31
2023/03/11 21:45:31.645240 api.go:295:    	 [INFO] 	mysql.master.status:&{mysql-bin.000054 678973655  true  true   3795d5b9-ad25-11ed-b9ba-c6bfa851d050:1-535969,
2023-03-12 05:45:31
4daf6505-ad25-11ed-8ade-12b5fa7e697d:1-1310294,
2023-03-12 05:45:31
67d598d1-ad25-11ed-87de-b21adafd20dc:1-7213830 0    }
2023-03-12 05:45:36
xenon:[{Tag:v1.1.4-34-gbae9e0d Time:2022/12/30 09:19:01 Git:bae9e0d GoVersion:go1.17.13 Platform:linux amd64}]
2023-03-12 05:45:36
2023/03/11 21:45:36.430180 xenon.go:71:    	 [INFO] 	main: tag=[v1.1.4-34-gbae9e0d], git=[bae9e0d], goversion=[go1.17.13], builddate=[2022/12/30 09:19:01]
2023-03-12 05:45:36
2023/03/11 21:45:36.430251 xenon.go:73:    	 [WARNING] 	xenon.conf.raft:[&{MetaDatadir:/var/lib/xenon HeartbeatTimeout:2000 AdmitDefeatHtCnt:5 ElectionTimeout:10000 PurgeBinlogInterval:300000 SuperIDLE:false LeaderStartCommand:/xenonchecker leaderStart LeaderStopCommand:/xenonchecker leaderStop PurgeBinlogDisabled:true RequestTimeout:2000 CandidateWaitFor2Nodes:60000}]
2023-03-12 05:45:36
2023/03/11 21:45:36.430268 xenon.go:74:    	 [WARNING] 	xenon.conf.mysql:[&{Admin:root Passwd: Host:127.0.0.1 Port:3306 Basedir:/u01/mysql_20160606/ Version:mysql80 DefaultsFile:/etc/my3306.cnf PingTimeout:2000 AdmitDefeatPingCnt:3 SemiSyncTimeoutForTwoNodes:10000 MasterSysVars:sync_binlog=default;innodb_flush_log_at_trx_commit=default SlaveSysVars:sync_binlog=1000;innodb_flush_log_at_trx_commit=1 MonitorDisabled:true ReplHost:pt1-xxx-xxx-mysqlcluster-mysql-2.pt1-xxx-xxx-mysqlcluster-mysql.middleware-webiz-mysqlcluster ReplUser:radondb_repl ReplPasswd:rCSIy2fPPTRh ReplGtidPurged:}]
2023-03-12 05:45:36
2023/03/11 21:45:36.430279 xenon.go:75:    	 [WARNING] 	xenon.conf.mysqld:[&{SSHHost: SSHUser: SSHPasswd: SSHPort:22 BackupDir:/u01/backup XtrabackupBinDir:. BackupIOPSLimits:100000 UseMemory:2GB Parallel:2 MysqldMonitorInterval:1000 MaxAllowedLocalTrxCount:0 Admin:root Passwd: Host:127.0.0.1 Port:3306 Basedir:/u01/mysql_20160606/ DefaultsFile:/etc/my3306.cnf}]
2023-03-12 05:45:36
2023/03/11 21:45:36.430356 trace.go:32:    	 [WARNING] 	FOLLOWER[ID:pt1-xxx-xxx-mysqlcluster-mysql-2.pt1-xxx-xxx-mysqlcluster-mysql.middleware-webiz-mysqlcluster:8801, V:0, E:0].prepare.to.recovery.peers.from.[/var/lib/xenon].peers[[pt1-xxx-xxx-mysqlcluster-mysql-0.pt1-xxx-xxx-mysqlcluster-mysql.middleware-webiz-mysqlcluster:8801 pt1-xxx-xxx-mysqlcluster-mysql-1.pt1-xxx-xxx-mysqlcluster-mysql.middleware-webiz-mysqlcluster:8801 pt1-xxx-xxx-mysqlcluster-mysql-2.pt1-xxx-xxx-mysqlcluster-mysql.middleware-webiz-mysqlcluster:8801]].idlePeers[[]]
2023-03-12 05:45:36
2023/03/11 21:45:36.430368 server.go:89:    	 [INFO] 	server.mysql.wait.for.work[maxwait:60s]
2023-03-12 05:45:36
2023/03/11 21:45:36.440633 api.go:285:    	 [INFO] 	mysql.slave.status:&{ 0  false  false        }
2023-03-12 05:45:36
2023/03/11 21:45:36.440873 api.go:295:    	 [INFO] 	mysql.master.status:&{mysql-bin.000054 679008369  true  true   3795d5b9-ad25-11ed-b9ba-c6bfa851d050:1-535969,
2023-03-12 05:45:36
4daf6505-ad25-11ed-8ade-12b5fa7e697d:1-1310294,
2023-03-12 05:45:36
67d598d1-ad25-11ed-87de-b21adafd20dc:1-7213896 0    }
2023-03-12 05:45:36
2023/03/11 21:45:36.440899 server.go:96:    	 [INFO] 	server.mysql.gtid:{Master_Log_File:mysql-bin.000054 Read_Master_Log_Pos:679008369 Relay_Master_Log_File: Slave_IO_Running:true Slave_IO_Running_Str: Slave_SQL_Running:true Slave_SQL_Running_Str: Retrieved_GTID_Set: Executed_GTID_Set:3795d5b9-ad25-11ed-b9ba-c6bfa851d050:1-535969,
2023-03-12 05:45:36
4daf6505-ad25-11ed-8ade-12b5fa7e697d:1-1310294,
2023-03-12 05:45:36
67d598d1-ad25-11ed-87de-b21adafd20dc:1-7213896 Seconds_Behind_Master:0 Slave_SQL_Running_State: Last_Error: Last_IO_Error: Last_SQL_Error:}
2023-03-12 05:45:36
2023/03/11 21:45:36.440905 server.go:98:    	 [INFO] 	server.mysql.set.to.READONLY
2023-03-12 05:45:36
2023/03/11 21:45:36.441267 server.go:104:    	 [INFO] 	server.mysql.start.slave
2023-03-12 05:45:36
2023/03/11 21:45:36.463925 server.go:106:    	 [ERROR] 	server.mysql.start.slave.error[Error 1200: The server is not configured as slave; fix in config file or with CHANGE MASTER TO]
2023-03-12 05:45:36
2023/03/11 21:45:36.463950 server.go:109:    	 [INFO] 	server.mysql.check.replication.user...
2023-03-12 05:45:36
2023/03/11 21:45:36.464307 server.go:123:    	 [INFO] 	server.mysql.setup.done
2023-03-12 05:45:36
2023/03/11 21:45:36.464323 server.go:129:    	 [INFO] 	server.prepare.setup.RPC
2023-03-12 05:45:36
2023/03/11 21:45:36.464445 server.go:163:    	 [INFO] 	server.RPC.setup.done
2023-03-12 05:45:36
2023/03/11 21:45:36.464464 api.go:29:    	 [INFO] 	mysql[127.0.0.1:3306].startping...
2023-03-12 05:45:36
2023/03/11 21:45:36.464476 trace.go:32:    	 [WARNING] 	FOLLOWER[ID:pt1-xxx-xxx-mysqlcluster-mysql-2.pt1-xxx-xxx-mysqlcluster-mysql.middleware-webiz-mysqlcluster:8801, V:0, E:0].raft.init.role.is.[UNKNOW]
2023-03-12 05:45:36
2023/03/11 21:45:36.464490 trace.go:27:    	 [INFO] 	FOLLOWER[ID:pt1-xxx-xxx-mysqlcluster-mysql-2.pt1-xxx-xxx-mysqlcluster-mysql.middleware-webiz-mysqlcluster:8801, V:0, E:0].raft.start...
2023-03-12 05:45:36
2023/03/11 21:45:36.464579 trace.go:27:    	 [INFO] 	FOLLOWER[ID:pt1-xxx-xxx-mysqlcluster-mysql-2.pt1-xxx-xxx-mysqlcluster-mysql.middleware-webiz-mysqlcluster:8801, V:0, E:0].start.CheckBrainSplit
2023-03-12 05:45:36
2023/03/11 21:45:36.464617 trace.go:32:    	 [WARNING] 	FOLLOWER[ID:pt1-xxx-xxx-mysqlcluster-mysql-2.pt1-xxx-xxx-mysqlcluster-mysql.middleware-webiz-mysqlcluster:8801, V:0, E:0].state.init
2023-03-12 05:45:36
2023/03/11 21:45:36.466267 xrpc.go:68:    	 [WARNING] 	xrpc.Start.listening.on[192.168.14.66:8801]
2023-03-12 05:45:36
2023/03/11 21:45:36.466282 server.go:189:    	 [INFO] 	server.start.success...
2023-03-12 05:45:36
2023/03/11 21:45:36.466287 xenon.go:81:    	 [INFO] 	xenon.start.success...
2023-03-12 05:45:36
2023/03/11 21:45:36.466462 admin.go:70:    	 [INFO] 	http.server.start[pt1-xxx-xxx-mysqlcluster-mysql-2.pt1-xxx-xxx-mysqlcluster-mysql.middleware-webiz-mysqlcluster:6601]...
2023-03-12 05:45:36
2023/03/11 21:45:36.834130 trace.go:32:    	 [WARNING] 	FOLLOWER[ID:pt1-xxx-xxx-mysqlcluster-mysql-2.pt1-xxx-xxx-mysqlcluster-mysql.middleware-webiz-mysqlcluster:8801, V:0, E:0].leaderStopShellCommand[[-c /xenonchecker leaderStop]].done
2023-03-12 05:45:36
2023/03/11 21:45:36.834156 trace.go:32:    	 [WARNING] 	FOLLOWER[ID:pt1-xxx-xxx-mysqlcluster-mysql-2.pt1-xxx-xxx-mysqlcluster-mysql.middleware-webiz-mysqlcluster:8801, V:0, E:0].mysql.waitMysqlDoneAsync.prepare
2023-03-12 05:45:36
2023/03/11 21:45:36.834173 trace.go:32:    	 [WARNING] 	FOLLOWER[ID:pt1-xxx-xxx-mysqlcluster-mysql-2.pt1-xxx-xxx-mysqlcluster-mysql.middleware-webiz-mysqlcluster:8801, V:0, E:0].state.machine.run
2023-03-12 05:45:36
2023/03/11 21:45:36.834603 trace.go:32:    	 [WARNING] 	FOLLOWER[ID:pt1-xxx-xxx-mysqlcluster-mysql-2.pt1-xxx-xxx-mysqlcluster-mysql.middleware-webiz-mysqlcluster:8801, V:0, E:0].mysql.SetReadOnly.done
2023-03-12 05:45:36
2023/03/11 21:45:36.834891 api.go:385:    	 [WARNING] 	mysql[127.0.0.1:3306].SetSlaveGlobalSysVar[sync_binlog=1000;innodb_flush_log_at_trx_commit=1]
2023-03-12 05:45:36
2023/03/11 21:45:36.834908 trace.go:32:    	 [WARNING] 	FOLLOWER[ID:pt1-xxx-xxx-mysqlcluster-mysql-2.pt1-xxx-xxx-mysqlcluster-mysql.middleware-webiz-mysqlcluster:8801, V:0, E:0].mysql.SetSlaveGlobalSysVar.done
2023-03-12 05:45:36
2023/03/11 21:45:36.834914 trace.go:32:    	 [WARNING] 	FOLLOWER[ID:pt1-xxx-xxx-mysqlcluster-mysql-2.pt1-xxx-xxx-mysqlcluster-mysql.middleware-webiz-mysqlcluster:8801, V:0, E:0].prepareAsync.done
2023-03-12 05:45:36
2023/03/11 21:45:36.837276 api.go:285:    	 [INFO] 	mysql.slave.status:&{ 0  false  false        }
2023-03-12 05:45:36
2023/03/11 21:45:36.837414 api.go:295:    	 [INFO] 	mysql.master.status:&{mysql-bin.000054 679008369  true  true   3795d5b9-ad25-11ed-b9ba-c6bfa851d050:1-535969,
2023-03-12 05:45:36
4daf6505-ad25-11ed-8ade-12b5fa7e697d:1-1310294,
2023-03-12 05:45:36
67d598d1-ad25-11ed-87de-b21adafd20dc:1-7213896 0    }
2023-03-12 05:45:36
2023/03/11 21:45:36.837430 trace.go:32:    	 [WARNING] 	FOLLOWER[ID:pt1-xxx-xxx-mysqlcluster-mysql-2.pt1-xxx-xxx-mysqlcluster-mysql.middleware-webiz-mysqlcluster:8801, V:0, E:0].init.my.gtid.is:{mysql-bin.000054 679008369  true  true   3795d5b9-ad25-11ed-b9ba-c6bfa851d050:1-535969,
2023-03-12 05:45:36
4daf6505-ad25-11ed-8ade-12b5fa7e697d:1-1310294,
2023-03-12 05:45:36
67d598d1-ad25-11ed-87de-b21adafd20dc:1-7213896 0    }
2023-03-12 05:45:41
2023/03/11 21:45:41.464676 trace.go:32:    	 [WARNING] 	FOLLOWER[ID:pt1-xxx-xxx-mysqlcluster-mysql-2.pt1-xxx-xxx-mysqlcluster-mysql.middleware-webiz-mysqlcluster:8801, V:0, E:0].ping.responses[1].is.less.than.half.maybe.brain.split
2023-03-12 05:45:41
2023/03/11 21:45:41.467899 trace.go:32:    	 [WARNING] 	FOLLOWER[ID:pt1-xxx-xxx-mysqlcluster-mysql-2.pt1-xxx-xxx-mysqlcluster-mysql.middleware-webiz-mysqlcluster:8801, V:0, E:0].ping.responses[2].is.greater.than.half.again
2023-03-12 05:45:45
2023/03/11 21:45:45.630679 trace.go:32:    	 [WARNING] 	FOLLOWER[ID:pt1-xxx-xxx-mysqlcluster-mysql-2.pt1-xxx-xxx-mysqlcluster-mysql.middleware-webiz-mysqlcluster:8801, V:0, E:0].get.voterequest.from[pt1-xxx-xxx-mysqlcluster-mysql-1.pt1-xxx-xxx-mysqlcluster-mysql.middleware-webiz-mysqlcluster:8801].request[{mysql-bin.000054 679008369  false No true Yes 67d598d1-ad25-11ed-87de-b21adafd20dc:2961113-7213896 3795d5b9-ad25-11ed-b9ba-c6bfa851d050:1-535969,
2023-03-12 05:45:45
4daf6505-ad25-11ed-8ade-12b5fa7e697d:1-1310294,
2023-03-12 05:45:45
67d598d1-ad25-11ed-87de-b21adafd20dc:1-7213896  Slave has read all relay log; waiting for more updates   }]
2023-03-12 05:45:45
2023/03/11 21:45:45.634947 api.go:285:    	 [INFO] 	mysql.slave.status:&{ 0  false  false        }
2023-03-12 05:45:45
2023/03/11 21:45:45.635328 api.go:295:    	 [INFO] 	mysql.master.status:&{mysql-bin.000054 679008369  true  true   3795d5b9-ad25-11ed-b9ba-c6bfa851d050:1-535969,
2023-03-12 05:45:45
4daf6505-ad25-11ed-8ade-12b5fa7e697d:1-1310294,
2023-03-12 05:45:45
67d598d1-ad25-11ed-87de-b21adafd20dc:1-7213896 0    }
2023-03-12 05:45:45
2023/03/11 21:45:45.635351 api.go:104:    	 [WARNING] 	mysql.gtid.compare.this[{mysql-bin.000054 679008369  true  true   3795d5b9-ad25-11ed-b9ba-c6bfa851d050:1-535969,
2023-03-12 05:45:45
4daf6505-ad25-11ed-8ade-12b5fa7e697d:1-1310294,
2023-03-12 05:45:45
67d598d1-ad25-11ed-87de-b21adafd20dc:1-7213896 0    }].from[&{mysql-bin.000054 679008369  false No true Yes 67d598d1-ad25-11ed-87de-b21adafd20dc:2961113-7213896 3795d5b9-ad25-11ed-b9ba-c6bfa851d050:1-535969,
2023-03-12 05:45:45
4daf6505-ad25-11ed-8ade-12b5fa7e697d:1-1310294,
2023-03-12 05:45:45
67d598d1-ad25-11ed-87de-b21adafd20dc:1-7213896  Slave has read all relay log; waiting for more updates   }]
2023-03-12 05:45:45
2023/03/11 21:45:45.635361 trace.go:32:    	 [WARNING] 	FOLLOWER[ID:pt1-xxx-xxx-mysqlcluster-mysql-2.pt1-xxx-xxx-mysqlcluster-mysql.middleware-webiz-mysqlcluster:8801, V:0, E:0].do.updateViewID[FROM:0 TO:6467]
2023-03-12 05:45:45
2023/03/11 21:45:45.635368 trace.go:32:    	 [WARNING] 	FOLLOWER[ID:pt1-xxx-xxx-mysqlcluster-mysql-2.pt1-xxx-xxx-mysqlcluster-mysql.middleware-webiz-mysqlcluster:8801, V:6467, E:0].get.requestvote.from[N:pt1-xxx-xxx-mysqlcluster-mysql-1.pt1-xxx-xxx-mysqlcluster-mysql.middleware-webiz-mysqlcluster:8801, V:6467, E:0].vote.for.this.candidate
2023-03-12 05:45:45
2023/03/11 21:45:45.635398 trace.go:32:    	 [WARNING] 	FOLLOWER[ID:pt1-xxx-xxx-mysqlcluster-mysql-2.pt1-xxx-xxx-mysqlcluster-mysql.middleware-webiz-mysqlcluster:8801, V:6467, E:0].get.voterequest.from[pt1-xxx-xxx-mysqlcluster-mysql-0.pt1-xxx-xxx-mysqlcluster-mysql.middleware-webiz-mysqlcluster:8801].request[{mysql-bin.000054 679008369  false No true Yes 67d598d1-ad25-11ed-87de-b21adafd20dc:2961113-7213896 3795d5b9-ad25-11ed-b9ba-c6bfa851d050:1-535969,
2023-03-12 05:45:45
4daf6505-ad25-11ed-8ade-12b5fa7e697d:1-1310294,
2023-03-12 05:45:45
67d598d1-ad25-11ed-87de-b21adafd20dc:1-7213896  Slave has read all relay log; waiting for more updates   }]
2023-03-12 05:45:45
2023/03/11 21:45:45.638163 api.go:285:    	 [INFO] 	mysql.slave.status:&{ 0  false  false        }
2023-03-12 05:45:45
2023/03/11 21:45:45.638296 api.go:295:    	 [INFO] 	mysql.master.status:&{mysql-bin.000054 679008369  true  true   3795d5b9-ad25-11ed-b9ba-c6bfa851d050:1-535969,
2023-03-12 05:45:45
4daf6505-ad25-11ed-8ade-12b5fa7e697d:1-1310294,
2023-03-12 05:45:45
67d598d1-ad25-11ed-87de-b21adafd20dc:1-7213896 0    }
2023-03-12 05:45:45
2023/03/11 21:45:45.638318 api.go:104:    	 [WARNING] 	mysql.gtid.compare.this[{mysql-bin.000054 679008369  true  true   3795d5b9-ad25-11ed-b9ba-c6bfa851d050:1-535969,
2023-03-12 05:45:45
4daf6505-ad25-11ed-8ade-12b5fa7e697d:1-1310294,
2023-03-12 05:45:45
67d598d1-ad25-11ed-87de-b21adafd20dc:1-7213896 0    }].from[&{mysql-bin.000054 679008369  false No true Yes 67d598d1-ad25-11ed-87de-b21adafd20dc:2961113-7213896 3795d5b9-ad25-11ed-b9ba-c6bfa851d050:1-535969,
2023-03-12 05:45:45
4daf6505-ad25-11ed-8ade-12b5fa7e697d:1-1310294,
2023-03-12 05:45:45
67d598d1-ad25-11ed-87de-b21adafd20dc:1-7213896  Slave has read all relay log; waiting for more updates   }]
2023-03-12 05:45:45
2023/03/11 21:45:45.638332 trace.go:32:    	 [WARNING] 	FOLLOWER[ID:pt1-xxx-xxx-mysqlcluster-mysql-2.pt1-xxx-xxx-mysqlcluster-mysql.middleware-webiz-mysqlcluster:8801, V:6467, E:0].get.requestvote.from[N:pt1-xxx-xxx-mysqlcluster-mysql-0.pt1-xxx-xxx-mysqlcluster-mysql.middleware-webiz-mysqlcluster:8801, V:6467, E:0].already.vote.for[pt1-xxx-xxx-mysqlcluster-mysql-1.pt1-xxx-xxx-mysqlcluster-mysql.middleware-webiz-mysqlcluster:8801].ret.reject
2023-03-12 05:45:51
2023/03/11 21:45:51.453062 trace.go:37:    	 [ERROR] 	FOLLOWER[ID:pt1-xxx-xxx-mysqlcluster-mysql-2.pt1-xxx-xxx-mysqlcluster-mysql.middleware-webiz-mysqlcluster:8801, V:6467, E:0].mysql.StartSlave.error[Error 1200: The server is not configured as slave; fix in config file or with CHANGE MASTER TO]
2023-03-12 05:45:51
2023/03/11 21:45:51.455756 api.go:285:    	 [INFO] 	mysql.slave.status:&{ 0  false  false        }
2023-03-12 05:45:51
2023/03/11 21:45:51.455929 api.go:295:    	 [INFO] 	mysql.master.status:&{mysql-bin.000054 679008369  true  true   3795d5b9-ad25-11ed-b9ba-c6bfa851d050:1-535969,
2023-03-12 05:45:51
4daf6505-ad25-11ed-8ade-12b5fa7e697d:1-1310294,
2023-03-12 05:45:51
67d598d1-ad25-11ed-87de-b21adafd20dc:1-7213896 0    }
2023-03-12 05:45:51
2023/03/11 21:45:51.455945 trace.go:32:    	 [WARNING] 	FOLLOWER[ID:pt1-xxx-xxx-mysqlcluster-mysql-2.pt1-xxx-xxx-mysqlcluster-mysql.middleware-webiz-mysqlcluster:8801, V:6467, E:0].get.heartbeat.my.gtid.is:{mysql-bin.000054 679008369  true  true   3795d5b9-ad25-11ed-b9ba-c6bfa851d050:1-535969,
2023-03-12 05:45:51
4daf6505-ad25-11ed-8ade-12b5fa7e697d:1-1310294,
2023-03-12 05:45:51
67d598d1-ad25-11ed-87de-b21adafd20dc:1-7213896 0    }
2023-03-12 05:45:51
2023/03/11 21:45:51.456243 mysql.go:137:    	 [INFO] 	mysql.get.local.uuid:[67d598d1-ad25-11ed-87de-b21adafd20dc]
2023-03-12 05:45:51
2023/03/11 21:45:51.456405 mysql.go:137:    	 [INFO] 	mysql.get.local.uuid:[67d598d1-ad25-11ed-87de-b21adafd20dc]
2023-03-12 05:45:51
2023/03/11 21:45:51.456603 api.go:173:    	 [WARNING] 	follower.gtid[&{mysql-bin.000054 679008369  true  true   3795d5b9-ad25-11ed-b9ba-c6bfa851d050:1-535969,
2023-03-12 05:45:51
4daf6505-ad25-11ed-8ade-12b5fa7e697d:1-1310294,
2023-03-12 05:45:51
67d598d1-ad25-11ed-87de-b21adafd20dc:1-7213896 0    }].bigger.than.remote[&{mysql-bin.000048 172049239  true  true   3795d5b9-ad25-11ed-b9ba-c6bfa851d050:1-535969,
2023-03-12 05:45:51
4daf6505-ad25-11ed-8ade-12b5fa7e697d:1-1310294,
2023-03-12 05:45:51
67d598d1-ad25-11ed-87de-b21adafd20dc:1-2961112 0    }]
2023-03-12 05:45:51
2023/03/11 21:45:51.456619 trace.go:32:    	 [WARNING] 	INVALID[ID:pt1-xxx-xxx-mysqlcluster-mysql-2.pt1-xxx-xxx-mysqlcluster-mysql.middleware-webiz-mysqlcluster:8801, V:6467, E:0].get.heartbeat.from[N:pt1-xxx-xxx-mysqlcluster-mysql-0.pt1-xxx-xxx-mysqlcluster-mysql.middleware-webiz-mysqlcluster:8801, V:6467, E:0].change.mysql.master
2023-03-12 05:45:51
2023/03/11 21:45:51.519364 trace.go:32:    	 [WARNING] 	INVALID[ID:pt1-xxx-xxx-mysqlcluster-mysql-2.pt1-xxx-xxx-mysqlcluster-mysql.middleware-webiz-mysqlcluster:8801, V:6467, E:0].get.heartbeat.change.to.the.new.master[pt1-xxx-xxx-mysqlcluster-mysql-0.pt1-xxx-xxx-mysqlcluster-mysql.middleware-webiz-mysqlcluster:8801].successed
2023-03-12 05:45:51
2023/03/11 21:45:51.519430 trace.go:32:    	 [WARNING] 	INVALID[ID:pt1-xxx-xxx-mysqlcluster-mysql-2.pt1-xxx-xxx-mysqlcluster-mysql.middleware-webiz-mysqlcluster:8801, V:6467, E:0].follower.state.machine.exit
2023-03-12 05:45:51
2023/03/11 21:45:51.629777 trace.go:32:    	 [WARNING] 	INVALID[ID:pt1-xxx-xxx-mysqlcluster-mysql-2.pt1-xxx-xxx-mysqlcluster-mysql.middleware-webiz-mysqlcluster:8801, V:6467, E:0].leaderStopShellCommand[[-c /xenonchecker leaderStop]].done
2023-03-12 05:45:51
2023/03/11 21:45:51.630414 api.go:385:    	 [WARNING] 	mysql[127.0.0.1:3306].SetSlaveGlobalSysVar[sync_binlog=1000;innodb_flush_log_at_trx_commit=1]

最近一小时的pprof数据文件

在xenon的日志里面发现大量的超时报错，怀疑是网络不稳定诱发的内存泄漏
2023-03-21 13:23:01
2023/03/21 05:23:01.405941 xenon.go:34:    	 [ERROR] 	api.v1.xenon.ping.error:get.client.error[dial tcp: i/o timeout]
2023-03-21 13:23:01
2023/03/21 05:23:01.405986 xenon.go:38:    	 [ERROR] 	api.v1.xenon.ping.error:rsp[nil] != [OK]
2023-03-21 13:23:06
2023/03/21 05:23:06.117067 xenon.go:34:    	 [ERROR] 	api.v1.xenon.ping.error:get.client.error[dial tcp: i/o timeout]
2023-03-21 13:23:06
2023/03/21 05:23:06.117109 xenon.go:38:    	 [ERROR] 	api.v1.xenon.ping.error:rsp[nil] != [OK]
2023-03-21 13:23:19
2023/03/21 05:23:19.873075 xenon.go:34:    	 [ERROR] 	api.v1.xenon.ping.error:get.client.error[dial tcp: i/o timeout]
2023-03-21 13:23:19
2023/03/21 05:23:19.873134 xenon.go:38:    	 [ERROR] 	api.v1.xenon.ping.error:rsp[nil] != [OK]
2023-03-21 13:23:33
2023/03/21 05:23:33.555762 trace.go:37:    	 [ERROR] 	LEADER[ID:pt1-xxx-xxx-mysqlcluster-mysql-2.pt1-xxx-xxx-mysqlcluster-mysql.middleware-xxx-mysqlcluster:8801, V:1104, E:0].send.heartbeat.to.peer[pt1-xxx-xxx-mysqlcluster-mysql-1.pt1-xxx-xxx-mysqlcluster-mysql.middleware-xxx-mysqlcluster:8801].new.client.error[dial tcp: i/o timeout]
2023-03-21 13:23:33
2023/03/21 05:23:33.555784 trace.go:37:    	 [ERROR] 	LEADER[ID:pt1-xxx-xxx-mysqlcluster-mysql-2.pt1-xxx-xxx-mysqlcluster-mysql.middleware-xxx-mysqlcluster:8801, V:1104, E:0].send.heartbeat.to.peer[pt1-xxx-xxx-mysqlcluster-mysql-0.pt1-xxx-xxx-mysqlcluster-mysql.middleware-xxx-mysqlcluster:8801].new.client.error[dial tcp: i/o timeout]
2023-03-21 13:24:57
2023/03/21 05:24:57.582294 trace.go:37:    	 [ERROR] 	LEADER[ID:pt1-xxx-xxx-mysqlcluster-mysql-2.pt1-xxx-xxx-mysqlcluster-mysql.middleware-xxx-mysqlcluster:8801, V:1104, E:0].send.heartbeat.to.peer[pt1-xxx-xxx-mysqlcluster-mysql-1.pt1-xxx-xxx-mysqlcluster-mysql.middleware-xxx-mysqlcluster:8801].new.client.error[dial tcp: i/o timeout]
2023-03-21 13:24:57
2023/03/21 05:24:57.582698 trace.go:37:    	 [ERROR] 	LEADER[ID:pt1-xxx-xxx-mysqlcluster-mysql-2.pt1-xxx-xxx-mysqlcluster-mysql.middleware-xxx-mysqlcluster:8801, V:1104, E:0].send.heartbeat.to.peer[pt1-xxx-xxx-mysqlcluster-mysql-0.pt1-xxx-xxx-mysqlcluster-mysql.middleware-xxx-mysqlcluster:8801].new.client.error[dial tcp: i/o timeout]
2023-03-21 13:24:59
2023/03/21 05:24:59.582913 trace.go:37:    	 [ERROR] 	LEADER[ID:pt1-xxx-xxx-mysqlcluster-mysql-2.pt1-xxx-xxx-mysqlcluster-mysql.middleware-xxx-mysqlcluster:8801, V:1106, E:0].send.heartbeat.to.peer[pt1-xxx-xxx-mysqlcluster-mysql-0.pt1-xxx-xxx-mysqlcluster-mysql.middleware-xxx-mysqlcluster:8801].new.client.error[dial tcp: i/o timeout]
2023-03-21 13:25:23
2023/03/21 05:25:23.588705 trace.go:37:    	 [ERROR] 	LEADER[ID:pt1-xxx-xxx-mysqlcluster-mysql-2.pt1-xxx-xxx-mysqlcluster-mysql.middleware-xxx-mysqlcluster:8801, V:1106, E:0].send.heartbeat.to.peer[pt1-xxx-xxx-mysqlcluster-mysql-0.pt1-xxx-xxx-mysqlcluster-mysql.middleware-xxx-mysqlcluster:8801].new.client.error[dial tcp: i/o timeout]
2023-03-21 13:25:23
2023/03/21 05:25:23.588723 trace.go:37:    	 [ERROR] 	LEADER[ID:pt1-xxx-xxx-mysqlcluster-mysql-2.pt1-xxx-xxx-mysqlcluster-mysql.middleware-xxx-mysqlcluster:8801, V:1106, E:0].send.heartbeat.to.peer[pt1-xxx-xxx-mysqlcluster-mysql-1.pt1-xxx-xxx-mysqlcluster-mysql.middleware-xxx-mysqlcluster:8801].new.client.error[dial tcp: i/o timeout]
2023-03-21 13:25:35
2023/03/21 05:25:35.591223 trace.go:37:    	 [ERROR] 	LEADER[ID:pt1-xxx-xxx-mysqlcluster-mysql-2.pt1-xxx-xxx-mysqlcluster-mysql.middleware-xxx-mysqlcluster:8801, V:1106, E:0].send.heartbeat.to.peer[pt1-xxx-xxx-mysqlcluster-mysql-1.pt1-xxx-xxx-mysqlcluster-mysql.middleware-xxx-mysqlcluster:8801].new.client.error[dial tcp: i/o timeout]
2023-03-21 13:25:35
2023/03/21 05:25:35.629203 trace.go:37:    	 [ERROR] 	LEADER[ID:pt1-xxx-xxx-mysqlcluster-mysql-2.pt1-xxx-xxx-mysqlcluster-mysql.middleware-xxx-mysqlcluster:8801, V:1106, E:0].send.heartbeat.to.peer[pt1-xxx-xxx-mysqlcluster-mysql-0.pt1-xxx-xxx-mysqlcluster-mysql.middleware-xxx-mysqlcluster:8801].new.client.error[dial tcp: i/o timeout]
2023-03-21 13:25:37
2023/03/21 05:25:37.591883 trace.go:37:    	 [ERROR] 	LEADER[ID:pt1-xxx-xxx-mysqlcluster-mysql-2.pt1-xxx-xxx-mysqlcluster-mysql.middleware-xxx-mysqlcluster:8801, V:1106, E:0].send.heartbeat.to.peer[pt1-xxx-xxx-mysqlcluster-mysql-0.pt1-xxx-xxx-mysqlcluster-mysql.middleware-xxx-mysqlcluster:8801].new.client.error[dial tcp: i/o timeout]
2023-03-21 13:25:59
2023/03/21 05:25:59.632408 trace.go:37:    	 [ERROR] 	LEADER[ID:pt1-xxx-xxx-mysqlcluster-mysql-2.pt1-xxx-xxx-mysqlcluster-mysql.middleware-xxx-mysqlcluster:8801, V:1108, E:0].send.heartbeat.to.peer[pt1-xxx-xxx-mysqlcluster-mysql-1.pt1-xxx-xxx-mysqlcluster-mysql.middleware-xxx-mysqlcluster:8801].new.client.error[dial tcp: i/o timeout]
2023-03-21 13:26:07
2023/03/21 05:26:07.635803 trace.go:37:    	 [ERROR] 	LEADER[ID:pt1-xxx-xxx-mysqlcluster-mysql-2.pt1-xxx-xxx-mysqlcluster-mysql.middleware-xxx-mysqlcluster:8801, V:1110, E:0].send.heartbeat.to.peer[pt1-xxx-xxx-mysqlcluster-mysql-0.pt1-xxx-xxx-mysqlcluster-mysql.middleware-xxx-mysqlcluster:8801].new.client.error[dial tcp: i/o timeout]
2023-03-21 13:26:15
2023/03/21 05:26:15.729216 trace.go:37:    	 [ERROR] 	LEADER[ID:pt1-xxx-xxx-mysqlcluster-mysql-2.pt1-xxx-xxx-mysqlcluster-mysql.middleware-xxx-mysqlcluster:8801, V:1112, E:0].send.heartbeat.to.peer[pt1-xxx-xxx-mysqlcluster-mysql-0.pt1-xxx-xxx-mysqlcluster-mysql.middleware-xxx-mysqlcluster:8801].new.client.error[dial tcp: i/o timeout]
2023-03-21 13:26:15
2023/03/21 05:26:15.729231 trace.go:37:    	 [ERROR] 	LEADER[ID:pt1-xxx-xxx-mysqlcluster-mysql-2.pt1-xxx-xxx-mysqlcluster-mysql.middleware-xxx-mysqlcluster:8801, V:1112, E:0].send.heartbeat.to.peer[pt1-xxx-xxx-mysqlcluster-mysql-1.pt1-xxx-xxx-mysqlcluster-mysql.middleware-xxx-mysqlcluster:8801].new.client.error[dial tcp: i/o timeout]
2023-03-21 13:26:35
2023/03/21 05:26:35.734855 trace.go:37:    	 [ERROR] 	LEADER[ID:pt1-xxx-xxx-mysqlcluster-mysql-2.pt1-xxx-xxx-mysqlcluster-mysql.middleware-xxx-mysqlcluster:8801, V:1112, E:0].send.heartbeat.to.peer[pt1-xxx-xxx-mysqlcluster-mysql-1.pt1-xxx-xxx-mysqlcluster-mysql.middleware-xxx-mysqlcluster:8801].new.client.error[dial tcp: i/o timeout]
2023-03-21 13:26:35
2023/03/21 05:26:35.734923 trace.go:37:    	 [ERROR] 	LEADER[ID:pt1-xxx-xxx-mysqlcluster-mysql-2.pt1-xxx-xxx-mysqlcluster-mysql.middleware-xxx-mysqlcluster:8801, V:1112, E:0].send.heartbeat.to.peer[pt1-xxx-xxx-mysqlcluster-mysql-0.pt1-xxx-xxx-mysqlcluster-mysql.middleware-xxx-mysqlcluster:8801].new.client.error[dial tcp: i/o timeout]
2023-03-21 13:26:37
2023/03/21 05:26:37.944991 raft.go:41:    	 [ERROR] 	api.v1.raft.status.error:get.client.error[dial tcp: i/o timeout]
2023-03-21 13:26:45
2023/03/21 05:26:45.738017 trace.go:37:    	 [ERROR] 	LEADER[ID:pt1-xxx-xxx-mysqlcluster-mysql-2.pt1-xxx-xxx-mysqlcluster-mysql.middleware-xxx-mysqlcluster:8801, V:1112, E:0].send.heartbeat.to.peer[pt1-xxx-xxx-mysqlcluster-mysql-1.pt1-xxx-xxx-mysqlcluster-mysql.middleware-xxx-mysqlcluster:8801].new.client.error[dial tcp: i/o timeout]
2023-03-21 13:26:45
2023/03/21 05:26:45.738056 trace.go:37:    	 [ERROR] 	LEADER[ID:pt1-xxx-xxx-mysqlcluster-mysql-2.pt1-xxx-xxx-mysqlcluster-mysql.middleware-xxx-mysqlcluster:8801, V:1112, E:0].send.heartbeat.to.peer[pt1-xxx-xxx-mysqlcluster-mysql-0.pt1-xxx-xxx-mysqlcluster-mysql.middleware-xxx-mysqlcluster:8801].new.client.error[dial tcp: i/o timeout]
2023-03-21 13:26:46
2023/03/21 05:26:46.835035 xenon.go:34:    	 [ERROR] 	api.v1.xenon.ping.error:get.client.error[dial tcp: i/o timeout]
2023-03-21 13:26:46
2023/03/21 05:26:46.835090 xenon.go:38:    	 [ERROR] 	api.v1.xenon.ping.error:rsp[nil] != [OK]
2023-03-21 13:27:24
2023/03/21 05:27:24.080753 raft.go:50:    	 [ERROR] 	api.v1.raft.status.error:get.client.error[dial tcp: i/o timeout]
2023-03-21 13:27:24
2023/03/21 05:27:24.080799 raft.go:54:    	 [ERROR] 	api.v1.raft.status.error:rsp[nil] != [OK]
2023-03-21 13:27:29
2023/03/21 05:27:29.447272 xenon.go:34:    	 [ERROR] 	api.v1.xenon.ping.error:get.client.error[dial tcp: i/o timeout]
2023-03-21 13:27:29
2023/03/21 05:27:29.447325 xenon.go:38:    	 [ERROR] 	api.v1.xenon.ping.error:rsp[nil] != [OK]
2023-03-21 13:27:45
2023/03/21 05:27:45.832517 trace.go:37:    	 [ERROR] 	LEADER[ID:pt1-xxx-xxx-mysqlcluster-mysql-2.pt1-xxx-xxx-mysqlcluster-mysql.middleware-xxx-mysqlcluster:8801, V:1112, E:0].send.heartbeat.to.peer[pt1-xxx-xxx-mysqlcluster-mysql-0.pt1-xxx-xxx-mysqlcluster-mysql.middleware-xxx-mysqlcluster:8801].new.client.error[dial tcp: i/o timeout]
2023-03-21 13:27:45
2023/03/21 05:27:45.832543 trace.go:37:    	 [ERROR] 	LEADER[ID:pt1-xxx-xxx-mysqlcluster-mysql-2.pt1-xxx-xxx-mysqlcluster-mysql.middleware-xxx-mysqlcluster:8801, V:1112, E:0].send.heartbeat.to.peer[pt1-xxx-xxx-mysqlcluster-mysql-1.pt1-xxx-xxx-mysqlcluster-mysql.middleware-xxx-mysqlcluster:8801].new.client.error[dial tcp: i/o timeout]
2023-03-21 13:27:55
2023/03/21 05:27:55.834930 trace.go:37:    	 [ERROR] 	LEADER[ID:pt1-xxx-xxx-mysqlcluster-mysql-2.pt1-xxx-xxx-mysqlcluster-mysql.middleware-xxx-mysqlcluster:8801, V:1112, E:0].send.heartbeat.to.peer[pt1-xxx-xxx-mysqlcluster-mysql-0.pt1-xxx-xxx-mysqlcluster-mysql.middleware-xxx-mysqlcluster:8801].new.client.error[dial tcp: i/o timeout]
2023-03-21 13:27:55
2023/03/21 05:27:55.835014 trace.go:37:    	 [ERROR] 	LEADER[ID:pt1-xxx-xxx-mysqlcluster-mysql-2.pt1-xxx-xxx-mysqlcluster-mysql.middleware-xxx-mysqlcluster:8801, V:1112, E:0].send.heartbeat.to.peer[pt1-xxx-xxx-mysqlcluster-mysql-1.pt1-xxx-xxx-mysqlcluster-mysql.middleware-xxx-mysqlcluster:8801].new.client.error[dial tcp: i/o timeout]
2023-03-21 13:28:32
2023/03/21 05:28:32.434789 raft.go:50:    	 [ERROR] 	api.v1.raft.status.error:get.client.error[dial tcp: i/o timeout]
2023-03-21 13:28:32
2023/03/21 05:28:32.434857 raft.go:54:    	 [ERROR] 	api.v1.raft.status.error:rsp[nil] != [OK]
2023-03-21 13:28:46
2023/03/21 05:28:46.463329 raft.go:50:    	 [ERROR] 	api.v1.raft.status.error:get.client.error[dial tcp: i/o timeout]
2023-03-21 13:28:46
2023/03/21 05:28:46.463384 raft.go:54:    	 [ERROR] 	api.v1.raft.status.error:rsp[nil] != [OK]
2023-03-21 13:31:41
2023/03/21 05:31:41.423579 raft.go:50:    	 [ERROR] 	api.v1.raft.status.error:get.client.error[dial tcp: i/o timeout]
2023-03-21 13:31:41
2023/03/21 05:31:41.423633 raft.go:54:    	 [ERROR] 	api.v1.raft.status.error:rsp[nil] != [OK]
2023-03-21 13:31:57
2023/03/21 05:31:57.729191 xenon.go:34:    	 [ERROR] 	api.v1.xenon.ping.error:get.client.error[dial tcp: i/o timeout]
2023-03-21 13:31:57
2023/03/21 05:31:57.729239 xenon.go:38:    	 [ERROR] 	api.v1.xenon.ping.error:rsp[nil] != [OK]
2023-03-21 13:31:59
2023/03/21 05:31:59.911988 trace.go:37:    	 [ERROR] 	LEADER[ID:pt1-xxx-xxx-mysqlcluster-mysql-2.pt1-xxx-xxx-mysqlcluster-mysql.middleware-xxx-mysqlcluster:8801, V:1112, E:0].send.heartbeat.to.peer[pt1-xxx-xxx-mysqlcluster-mysql-0.pt1-xxx-xxx-mysqlcluster-mysql.middleware-xxx-mysqlcluster:8801].new.client.error[dial tcp: i/o timeout]
2023-03-21 13:31:59
2023/03/21 05:31:59.912042 trace.go:37:    	 [ERROR] 	LEADER[ID:pt1-xxx-xxx-mysqlcluster-mysql-2.pt1-xxx-xxx-mysqlcluster-mysql.middleware-xxx-mysqlcluster:8801, V:1112, E:0].send.heartbeat.to.peer[pt1-xxx-xxx-mysqlcluster-mysql-1.pt1-xxx-xxx-mysqlcluster-mysql.middleware-xxx-mysqlcluster:8801].new.client.error[dial tcp: i/o timeout]
2023-03-21 13:32:11
2023/03/21 05:32:11.544343 raft.go:50:    	 [ERROR] 	api.v1.raft.status.error:get.client.error[dial tcp: i/o timeout]
2023-03-21 13:32:11
2023/03/21 05:32:11.544380 raft.go:54:    	 [ERROR] 	api.v1.raft.status.error:rsp[nil] != [OK]
2023-03-21 13:32:15
2023/03/21 05:32:15.915863 trace.go:37:    	 [ERROR] 	LEADER[ID:pt1-xxx-xxx-mysqlcluster-mysql-2.pt1-xxx-xxx-mysqlcluster-mysql.middleware-xxx-mysqlcluster:8801, V:1112, E:0].send.heartbeat.to.peer[pt1-xxx-xxx-mysqlcluster-mysql-1.pt1-xxx-xxx-mysqlcluster-mysql.middleware-xxx-mysqlcluster:8801].new.client.error[dial tcp: i/o timeout]
2023-03-21 13:32:15
2023/03/21 05:32:15.915909 trace.go:37:    	 [ERROR] 	LEADER[ID:pt1-xxx-xxx-mysqlcluster-mysql-2.pt1-xxx-xxx-mysqlcluster-mysql.middleware-xxx-mysqlcluster:8801, V:1112, E:0].send.heartbeat.to.peer[pt1-xxx-xxx-mysqlcluster-mysql-0.pt1-xxx-xxx-mysqlcluster-mysql.middleware-xxx-mysqlcluster:8801].new.client.error[dial tcp: i/o timeout]
2023-03-21 13:32:27
2023/03/21 05:32:27.919680 trace.go:37:    	 [ERROR] 	LEADER[ID:pt1-xxx-xxx-mysqlcluster-mysql-2.pt1-xxx-xxx-mysqlcluster-mysql.middleware-xxx-mysqlcluster:8801, V:1112, E:0].send.heartbeat.to.peer[pt1-xxx-xxx-mysqlcluster-mysql-1.pt1-xxx-xxx-mysqlcluster-mysql.middleware-xxx-mysqlcluster:8801].new.client.error[dial tcp: i/o timeout]
2023-03-21 13:32:27
2023/03/21 05:32:27.919680 trace.go:37:    	 [ERROR] 	LEADER[ID:pt1-xxx-xxx-mysqlcluster-mysql-2.pt1-xxx-xxx-mysqlcluster-mysql.middleware-xxx-mysqlcluster:8801, V:1112, E:0].send.heartbeat.to.peer[pt1-xxx-xxx-mysqlcluster-mysql-0.pt1-xxx-xxx-mysqlcluster-mysql.middleware-xxx-mysqlcluster:8801].new.client.error[dial tcp: i/o timeout]
2023-03-21 13:32:51
2023/03/21 05:32:51.925993 trace.go:37:    	 [ERROR] 	LEADER[ID:pt1-xxx-xxx-mysqlcluster-mysql-2.pt1-xxx-xxx-mysqlcluster-mysql.middleware-xxx-mysqlcluster:8801, V:1114, E:0].send.heartbeat.to.peer[pt1-xxx-xxx-mysqlcluster-mysql-0.pt1-xxx-xxx-mysqlcluster-mysql.middleware-xxx-mysqlcluster:8801].new.client.error[dial tcp: i/o timeout]
2023-03-21 13:33:01
2023/03/21 05:33:01.708331 xenon.go:34:    	 [ERROR] 	api.v1.xenon.ping.error:get.client.error[dial tcp: i/o timeout]
2023-03-21 13:33:01
2023/03/21 05:33:01.708378 xenon.go:38:    	 [ERROR] 	api.v1.xenon.ping.error:rsp[nil] != [OK]
2023-03-21 13:33:04
2023/03/21 05:33:04.975742 raft.go:41:    	 [ERROR] 	api.v1.raft.status.error:get.client.error[dial tcp: i/o timeout]
2023-03-21 13:33:29
2023/03/21 05:33:29.936776 trace.go:37:    	 [ERROR] 	LEADER[ID:pt1-xxx-xxx-mysqlcluster-mysql-2.pt1-xxx-xxx-mysqlcluster-mysql.middleware-xxx-mysqlcluster:8801, V:1114, E:0].send.heartbeat.to.peer[pt1-xxx-xxx-mysqlcluster-mysql-0.pt1-xxx-xxx-mysqlcluster-mysql.middleware-xxx-mysqlcluster:8801].new.client.error[dial tcp: i/o timeout]
2023-03-21 13:33:29
2023/03/21 05:33:29.936805 trace.go:37:    	 [ERROR] 	LEADER[ID:pt1-xxx-xxx-mysqlcluster-mysql-2.pt1-xxx-xxx-mysqlcluster-mysql.middleware-xxx-mysqlcluster:8801, V:1114, E:0].send.heartbeat.to.peer[pt1-xxx-xxx-mysqlcluster-mysql-1.pt1-xxx-xxx-mysqlcluster-mysql.middleware-xxx-mysqlcluster:8801].new.client.error[dial tcp: i/o timeout]
2023-03-21 13:33:38
2023/03/21 05:33:38.652104 raft.go:50:    	 [ERROR] 	api.v1.raft.status.error:get.client.error[dial tcp: i/o timeout]
2023-03-21 13:33:38
2023/03/21 05:33:38.652177 raft.go:54:    	 [ERROR] 	api.v1.raft.status.error:rsp[nil] != [OK]
2023-03-21 13:33:41
2023/03/21 05:33:41.940672 trace.go:37:    	 [ERROR] 	LEADER[ID:pt1-xxx-xxx-mysqlcluster-mysql-2.pt1-xxx-xxx-mysqlcluster-mysql.middleware-xxx-mysqlcluster:8801, V:1114, E:0].send.heartbeat.to.peer[pt1-xxx-xxx-mysqlcluster-mysql-1.pt1-xxx-xxx-mysqlcluster-mysql.middleware-xxx-mysqlcluster:8801].new.client.error[dial tcp: i/o timeout]
2023-03-21 13:33:41
2023/03/21 05:33:41.940694 trace.go:37:    	 [ERROR] 	LEADER[ID:pt1-xxx-xxx-mysqlcluster-mysql-2.pt1-xxx-xxx-mysqlcluster-mysql.middleware-xxx-mysqlcluster:8801, V:1114, E:0].send.heartbeat.to.peer[pt1-xxx-xxx-mysqlcluster-mysql-0.pt1-xxx-xxx-mysqlcluster-mysql.middleware-xxx-mysqlcluster:8801].new.client.error[dial tcp: i/o timeout]
2023-03-21 13:34:02
2023/03/21 05:34:02.461251 raft.go:41:    	 [ERROR] 	api.v1.raft.status.error:get.client.error[dial tcp: i/o timeout]
2023-03-21 13:34:05
2023/03/21 05:34:05.947366 trace.go:37:    	 [ERROR] 	LEADER[ID:pt1-xxx-xxx-mysqlcluster-mysql-2.pt1-xxx-xxx-mysqlcluster-mysql.middleware-xxx-mysqlcluster:8801, V:1114, E:0].send.heartbeat.to.peer[pt1-xxx-xxx-mysqlcluster-mysql-1.pt1-xxx-xxx-mysqlcluster-mysql.middleware-xxx-mysqlcluster:8801].new.client.error[dial tcp: i/o timeout]
2023-03-21 13:34:05
2023/03/21 05:34:05.947385 trace.go:37:    	 [ERROR] 	LEADER[ID:pt1-xxx-xxx-mysqlcluster-mysql-2.pt1-xxx-xxx-mysqlcluster-mysql.middleware-xxx-mysqlcluster:8801, V:1114, E:0].send.heartbeat.to.peer[pt1-xxx-xxx-mysqlcluster-mysql-0.pt1-xxx-xxx-mysqlcluster-mysql.middleware-xxx-mysqlcluster:8801].new.client.error[dial tcp: i/o timeout]
2023-03-21 13:34:07
2023/03/21 05:34:07.947863 trace.go:37:    	 [ERROR] 	LEADER[ID:pt1-xxx-xxx-mysqlcluster-mysql-2.pt1-xxx-xxx-mysqlcluster-mysql.middleware-xxx-mysqlcluster:8801, V:1114, E:0].send.heartbeat.to.peer[pt1-xxx-xxx-mysqlcluster-mysql-0.pt1-xxx-xxx-mysqlcluster-mysql.middleware-xxx-mysqlcluster:8801].new.client.error[dial tcp: i/o timeout]
2023-03-21 13:34:07
2023/03/21 05:34:07.947904 trace.go:37:    	 [ERROR] 	LEADER[ID:pt1-xxx-xxx-mysqlcluster-mysql-2.pt1-xxx-xxx-mysqlcluster-mysql.middleware-xxx-mysqlcluster:8801, V:1114, E:0].send.heartbeat.to.peer[pt1-xxx-xxx-mysqlcluster-mysql-1.pt1-xxx-xxx-mysqlcluster-mysql.middleware-xxx-mysqlcluster:8801].new.client.error[dial tcp: i/o timeout]
2023-03-21 13:34:22
2023/03/21 05:34:22.742297 raft.go:50:    	 [ERROR] 	api.v1.raft.status.error:get.client.error[dial tcp: i/o timeout]
2023-03-21 13:34:22
2023/03/21 05:34:22.742342 raft.go:54:    	 [ERROR] 	api.v1.raft.status.error:rsp[nil] != [OK]
2023-03-21 13:34:25
2023/03/21 05:34:25.953419 trace.go:37:    	 [ERROR] 	LEADER[ID:pt1-xxx-xxx-mysqlcluster-mysql-2.pt1-xxx-xxx-mysqlcluster-mysql.middleware-xxx-mysqlcluster:8801, V:1114, E:0].send.heartbeat.to.peer[pt1-xxx-xxx-mysqlcluster-mysql-0.pt1-xxx-xxx-mysqlcluster-mysql.middleware-xxx-mysqlcluster:8801].new.client.error[dial tcp: i/o timeout]
2023-03-21 13:34:25
2023/03/21 05:34:25.953454 trace.go:37:    	 [ERROR] 	LEADER[ID:pt1-xxx-xxx-mysqlcluster-mysql-2.pt1-xxx-xxx-mysqlcluster-mysql.middleware-xxx-mysqlcluster:8801, V:1114, E:0].send.heartbeat.to.peer[pt1-xxx-xxx-mysqlcluster-mysql-1.pt1-xxx-xxx-mysqlcluster-mysql.middleware-xxx-mysqlcluster:8801].new.client.error[dial tcp: i/o timeout]
2023-03-21 13:34:34
2023/03/21 05:34:34.631296 xenon.go:34:    	 [ERROR] 	api.v1.xenon.ping.error:get.client.error[dial tcp: i/o timeout]
2023-03-21 13:34:34
2023/03/21 05:34:34.631344 xenon.go:38:    	 [ERROR] 	api.v1.xenon.ping.error:rsp[nil] != [OK]
2023-03-21 13:34:35
2023/03/21 05:34:35.955665 trace.go:37:    	 [ERROR] 	LEADER[ID:pt1-xxx-xxx-mysqlcluster-mysql-2.pt1-xxx-xxx-mysqlcluster-mysql.middleware-xxx-mysqlcluster:8801, V:1114, E:0].send.heartbeat.to.peer[pt1-xxx-xxx-mysqlcluster-mysql-0.pt1-xxx-xxx-mysqlcluster-mysql.middleware-xxx-mysqlcluster:8801].new.client.error[dial tcp: i/o timeout]
2023-03-21 13:34:35
2023/03/21 05:34:35.955696 trace.go:37:    	 [ERROR] 	LEADER[ID:pt1-xxx-xxx-mysqlcluster-mysql-2.pt1-xxx-xxx-mysqlcluster-mysql.middleware-xxx-mysqlcluster:8801, V:1114, E:0].send.heartbeat.to.peer[pt1-xxx-xxx-mysqlcluster-mysql-1.pt1-xxx-xxx-mysqlcluster-mysql.middleware-xxx-mysqlcluster:8801].new.client.error[dial tcp: i/o timeout]
2023-03-21 13:34:37
2023/03/21 05:34:37.956152 trace.go:37:    	 [ERROR] 	LEADER[ID:pt1-xxx-xxx-mysqlcluster-mysql-2.pt1-xxx-xxx-mysqlcluster-mysql.middleware-xxx-mysqlcluster:8801, V:1114, E:0].send.heartbeat.to.peer[pt1-xxx-xxx-mysqlcluster-mysql-0.pt1-xxx-xxx-mysqlcluster-mysql.middleware-xxx-mysqlcluster:8801].new.client.error[dial tcp: i/o timeout]
2023-03-21 13:34:37
2023/03/21 05:34:37.956190 trace.go:37:    	 [ERROR] 	LEADER[ID:pt1-xxx-xxx-mysqlcluster-mysql-2.pt1-xxx-xxx-mysqlcluster-mysql.middleware-xxx-mysqlcluster:8801, V:1114, E:0].send.heartbeat.to.peer[pt1-xxx-xxx-mysqlcluster-mysql-1.pt1-xxx-xxx-mysqlcluster-mysql.middleware-xxx-mysqlcluster:8801].new.client.error[dial tcp: i/o timeout]
2023-03-21 13:34:45
2023/03/21 05:34:45.958004 trace.go:37:    	 [ERROR] 	LEADER[ID:pt1-xxx-xxx-mysqlcluster-mysql-2.pt1-xxx-xxx-mysqlcluster-mysql.middleware-xxx-mysqlcluster:8801, V:1114, E:0].send.heartbeat.to.peer[pt1-xxx-xxx-mysqlcluster-mysql-1.pt1-xxx-xxx-mysqlcluster-mysql.middleware-xxx-mysqlcluster:8801].new.client.error[dial tcp: i/o timeout]
2023-03-21 13:34:45
2023/03/21 05:34:45.958022 trace.go:37:    	 [ERROR] 	LEADER[ID:pt1-xxx-xxx-mysqlcluster-mysql-2.pt1-xxx-xxx-mysqlcluster-mysql.middleware-xxx-mysqlcluster:8801, V:1114, E:0].send.heartbeat.to.peer[pt1-xxx-xxx-mysqlcluster-mysql-0.pt1-xxx-xxx-mysqlcluster-mysql.middleware-xxx-mysqlcluster:8801].new.client.error[dial tcp: i/o timeout]
2023-03-21 13:34:47
2023/03/21 05:34:47.958748 trace.go:37:    	 [ERROR] 	LEADER[ID:pt1-xxx-xxx-mysqlcluster-mysql-2.pt1-xxx-xxx-mysqlcluster-mysql.middleware-xxx-mysqlcluster:8801, V:1114, E:0].send.heartbeat.to.peer[pt1-xxx-xxx-mysqlcluster-mysql-0.pt1-xxx-xxx-mysqlcluster-mysql.middleware-xxx-mysqlcluster:8801].new.client.error[dial tcp: i/o timeout]
2023-03-21 13:34:47
2023/03/21 05:34:47.958763 trace.go:37:    	 [ERROR] 	LEADER[ID:pt1-xxx-xxx-mysqlcluster-mysql-2.pt1-xxx-xxx-mysqlcluster-mysql.middleware-xxx-mysqlcluster:8801, V:1114, E:0].send.heartbeat.to.peer[pt1-xxx-xxx-mysqlcluster-mysql-1.pt1-xxx-xxx-mysqlcluster-mysql.middleware-xxx-mysqlcluster:8801].new.client.error[dial tcp: i/o timeout]
2023-03-21 13:34:59
2023/03/21 05:34:59.963647 trace.go:37:    	 [ERROR] 	LEADER[ID:pt1-xxx-xxx-mysqlcluster-mysql-2.pt1-xxx-xxx-mysqlcluster-mysql.middleware-xxx-mysqlcluster:8801, V:1114, E:0].send.heartbeat.to.peer[pt1-xxx-xxx-mysqlcluster-mysql-1.pt1-xxx-xxx-mysqlcluster-mysql.middleware-xxx-mysqlcluster:8801].new.client.error[dial tcp: i/o timeout]
2023-03-21 13:35:06
2023/03/21 05:35:06.332125 raft.go:50:    	 [ERROR] 	api.v1.raft.status.error:get.client.error[dial tcp: i/o timeout]
2023-03-21 13:35:06
2023/03/21 05:35:06.332188 raft.go:54:    	 [ERROR] 	api.v1.raft.status.error:rsp[nil] != [OK]
2023-03-21 13:35:10
2023/03/21 05:35:10.582580 xenon.go:34:    	 [ERROR] 	api.v1.xenon.ping.error:get.client.error[dial tcp: i/o timeout]
2023-03-21 13:35:10
2023/03/21 05:35:10.582627 xenon.go:38:    	 [ERROR] 	api.v1.xenon.ping.error:rsp[nil] != [OK]
2023-03-21 13:35:19
2023/03/21 05:35:19.228629 raft.go:50:    	 [ERROR] 	api.v1.raft.status.error:get.client.error[dial tcp: i/o timeout]
2023-03-21 13:35:19
2023/03/21 05:35:19.228667 raft.go:54:    	 [ERROR] 	api.v1.raft.status.error:rsp[nil] != [OK]
2023-03-21 13:35:36
2023/03/21 05:35:36.876066 xenon.go:34:    	 [ERROR] 	api.v1.xenon.ping.error:get.client.error[dial tcp: i/o timeout]
2023-03-21 13:35:36
2023/03/21 05:35:36.876115 xenon.go:38:    	 [ERROR] 	api.v1.xenon.ping.error:rsp[nil] != [OK]
2023-03-21 13:35:37
2023/03/21 05:35:37.950505 xenon.go:34:    	 [ERROR] 	api.v1.xenon.ping.error:get.client.error[dial tcp: i/o timeout]
2023-03-21 13:35:37
2023/03/21 05:35:37.950560 xenon.go:38:    	 [ERROR] 	api.v1.xenon.ping.error:rsp[nil] != [OK]
2023-03-21 13:35:37
2023/03/21 05:35:37.973035 trace.go:37:    	 [ERROR] 	LEADER[ID:pt1-xxx-xxx-mysqlcluster-mysql-2.pt1-xxx-xxx-mysqlcluster-mysql.middleware-xxx-mysqlcluster:8801, V:1116, E:0].send.heartbeat.to.peer[pt1-xxx-xxx-mysqlcluster-mysql-1.pt1-xxx-xxx-mysqlcluster-mysql.middleware-xxx-mysqlcluster:8801].new.client.error[dial tcp: i/o timeout]
2023-03-21 13:35:55
2023/03/21 05:35:55.978950 trace.go:37:    	 [ERROR] 	LEADER[ID:pt1-xxx-xxx-mysqlcluster-mysql-2.pt1-xxx-xxx-mysqlcluster-mysql.middleware-xxx-mysqlcluster:8801, V:1118, E:0].send.heartbeat.to.peer[pt1-xxx-xxx-mysqlcluster-mysql-0.pt1-xxx-xxx-mysqlcluster-mysql.middleware-xxx-mysqlcluster:8801].new.client.error[dial tcp: i/o timeout]
2023-03-21 13:35:57
2023/03/21 05:35:57.790222 xenon.go:34:    	 [ERROR] 	api.v1.xenon.ping.error:get.client.error[dial tcp: i/o timeout]
2023-03-21 13:35:57
2023/03/21 05:35:57.790257 xenon.go:38:    	 [ERROR] 	api.v1.xenon.ping.error:rsp[nil] != [OK]
2023-03-21 13:36:00
2023/03/21 05:36:00.974670 xenon.go:34:    	 [ERROR] 	api.v1.xenon.ping.error:get.client.error[dial tcp: i/o timeout]
2023-03-21 13:36:00
2023/03/21 05:36:00.974719 xenon.go:38:    	 [ERROR] 	api.v1.xenon.ping.error:rsp[nil] != [OK]
2023-03-21 13:36:01
2023/03/21 05:36:01.981230 trace.go:37:    	 [ERROR] 	LEADER[ID:pt1-xxx-xxx-mysqlcluster-mysql-2.pt1-xxx-xxx-mysqlcluster-mysql.middleware-xxx-mysqlcluster:8801, V:1120, E:0].send.heartbeat.to.peer[pt1-xxx-xxx-mysqlcluster-mysql-0.pt1-xxx-xxx-mysqlcluster-mysql.middleware-xxx-mysqlcluster:8801].new.client.error[dial tcp: i/o timeout]
2023-03-21 13:36:01
2023/03/21 05:36:01.981253 trace.go:37:    	 [ERROR] 	LEADER[ID:pt1-xxx-xxx-mysqlcluster-mysql-2.pt1-xxx-xxx-mysqlcluster-mysql.middleware-xxx-mysqlcluster:8801, V:1120, E:0].send.heartbeat.to.peer[pt1-xxx-xxx-mysqlcluster-mysql-1.pt1-xxx-xxx-mysqlcluster-mysql.middleware-xxx-mysqlcluster:8801].new.client.error[dial tcp: i/o timeout]
2023-03-21 13:36:10
2023/03/21 05:36:10.630171 xenon.go:34:    	 [ERROR] 	api.v1.xenon.ping.error:get.client.error[dial tcp: i/o timeout]
2023-03-21 13:36:10
2023/03/21 05:36:10.630212 xenon.go:38:    	 [ERROR] 	api.v1.xenon.ping.error:rsp[nil] != [OK]
2023-03-21 13:36:15
2023/03/21 05:36:15.986753 trace.go:37:    	 [ERROR] 	LEADER[ID:pt1-xxx-xxx-mysqlcluster-mysql-2.pt1-xxx-xxx-mysqlcluster-mysql.middleware-xxx-mysqlcluster:8801, V:1120, E:0].send.heartbeat.to.peer[pt1-xxx-xxx-mysqlcluster-mysql-0.pt1-xxx-xxx-mysqlcluster-mysql.middleware-xxx-mysqlcluster:8801].new.client.error[dial tcp: i/o timeout]

没有重现

这是来自QQ邮箱的假期自动回复邮件。

您好，邮件我已收到，尽快给您回复。

authors: acekingke liarby zhl003

repo: radondb/radondb-mysql-kubernetes


text:
Could not find 'Radzen.createDatePicker'

After updating the system to the latest version, 4.28.3, the system presented the error below Procedure to reproduce Install the nuget version 4.28.4 through visual studio, in a Blazor Server project, use the DataPicker component, as follows
<RadzenDatePicker @bind-Value="variable" DateFormat="dd/MM/yyyy" Change="OnChangeAction">
--------Error---------
Error: Could not find 'Radzen.createDatePicker' ('createDatePicker' was undefined).
at http://localhost:5191/_framework/blazor.server.js:1:734
at Array.forEach ()
at l.findFunction (http://localhost:5191/_framework/blazor.server.js:1:702)
at _ (http://localhost:5191/_framework/blazor.server.js:1:5445)
at http://localhost:5191/_framework/blazor.server.js:1:3238
at new Promise ()
at y.beginInvokeJSFromDotNet (http://localhost:5191/_framework/blazor.server.js:1:3201)
at Yt._invokeClientMethod (http://localhost:5191/_framework/blazor.server.js:1:61084)
at Yt._processIncomingData (http://localhost:5191/_framework/blazor.server.js:1:58559)
at Yt.connection.onreceive (http://localhost:5191/_framework/blazor.server.js:1:52200)
at Microsoft.JSInterop.JSRuntime.InvokeAsync[TValue](Int64 targetInstanceId, String identifier, Object[] args)
at Microsoft.JSInterop.JSRuntimeExtensions.InvokeVoidAsync(IJSRuntime jsRuntime, String identifier, Object[] args)
at Radzen.Blazor.RadzenDatePicker`1.OnAfterRenderAsync(Boolean firstRender)
at Microsoft.AspNetCore.Components.RenderTree.Renderer.GetErrorHandledTask(Task taskToHandle, ComponentState owningComponentState)

Check this forum thread: https://forum.radzen.com/t/error-after-update-with-no-code-change/16773

source: gharchive/issue

authors: ExceptionBrasil akorchev

repo: radzenhq/radzen-blazor

license: MIT

license_type: permissive

license_source: github-api


text:
requestPermissionToSendNotifications() completes immediately

Rules

To report a bug and help us to provide the solution as fast as possible, please follow the instructions below:
1 - Describe the bug
AwesomeNotifications().requestPermissionToSendNotifications(); finnished immiditally, which makes no sense and the result also useless. My use case is that I have to wait for the permission request to be done and continue with
2 - Provide us as much information as possible
To help us to understand your issue, provide with your bug report all the relevant informations, such as:

Your plugins list inside the file pubspec.yaml (at least all notification plugins)
What platform did you found the issue
What devices did you found the issue
How are you initializing the plugin
How are you creating the notification
The output of flutter doctor command

OBS: To post a source code in your issue, please use the markdown below:
print('Your source code goes here');

3 - How To Reproduce the Error
Steps to reproduce the behavior:

Go to '...'
Click on '....'
Scroll down to '....'
See error

...or if you prefer, you can provide us a simple example app on GitHub with the issue already reproduced instead of the steps 2 and 3.
4 - Expected behavior
A clear and concise description of what you expected to happen.
5 - Screenshots
If applicable, add screenshots to help explain your problem.
6 - Additional context
Add any other context about the problem here.

Well, as no other information was provided, the only thing that i can imagine is that you're may forgot to use the keyword await in front of any method with Future returned.

I did added await, and it still completes without waiting for the user interaction.

@MatyasK i need you to fill the other informations requested in the form. I can't help you without these informations.

authors: MatyasK rafaelsetragni


text:
JSDoc snippet doesn't work

The snippet for adding a comment still doesn't work

///
NVIM v0.8.3
Build type: Release
LuaJIT 2.1.0-beta3
Compiled by brew@Ventura-arm64.local
///

Hey @rwxmad , did you add this line to your config?
require("luasnip").filetype_extend("javascript", { "jsdoc" })

Hey @rwxmad , did you add this line to your config?
require("luasnip").filetype_extend("javascript", { "jsdoc" })

thanks a lot, this solved my problem

authors: OkelleyDevelopment rwxmad

repo: rafamadriz/friendly-snippets


text:
cellsize returns erroneous results for grids with fine spacing [no reprojeciton]

This makes sense as gridsize is increasing linearly with latitude
using Rasters
using Rasters.Lookups
import GeoFormatTypes as GFT
using Plots

dX = 0.1
dY = -0.1
lon = X(Projected(166.:dX:168.; sampling=Intervals(Start()), order=ForwardOrdered(), span=Regular(dX), crs=EPSG(4326)))
lat = Y(Projected(-78.0:dY:-80.; sampling=Intervals(Start()), order=ForwardOrdered(), span=Regular(dY ), crs=EPSG(4326)))
ras = Raster(rand(lon, lat))
cell_area = Rasters.cellsize(ras)
plot(cell_area[1, :])

if we decrease the step size in X we start to see some jutter
dX = 0.0006
dY = -0.1
lon = X(Projected(166.0:dX:168.0; sampling=Intervals(Start()), order=ForwardOrdered(), span=Regular(dX), crs=EPSG(4326)))
lat = Y(Projected(-78.0:dY:-80.0; sampling=Intervals(Start()), order=ForwardOrdered(), span=Regular(dY), crs=EPSG(4326)))
ras = Raster(rand(lon, lat))
cell_area = Rasters.cellsize(ras)
plot(cell_area[1, :])

and things really fall apart when we decrease step size in X and Y
dX = 0.0006
dY = -0.0003
lon = X(Projected(166.0:dX:167.0; sampling=Intervals(Start()), order=ForwardOrdered(), span=Regular(dX), crs=EPSG(4326)))
lat = Y(Projected(-78.0:dY:-79.0; sampling=Intervals(Start()), order=ForwardOrdered(), span=Regular(dY), crs=EPSG(4326)))
ras = Raster(rand(lon, lat))
cell_area = Rasters.cellsize(ras)
plot(cell_area[1, :])

@alex-s-gardner can you confirm this is on v0.11.8 of Rasters.jl?

Yes, it is v0.11.8

I wonder if we need to densify and subsample points on the grid?  I would expect that to have an effect as we increase dx and dy though, not as we decrease...
https://github.com/rafaqz/Rasters.jl/blob/8d13c1887f90444d24e3c19ecbff42c8d5f0de68/ext/RastersArchGDALExt/cellsize.jl#L71-L77

Seems like a precision issue to me... is Float64 geometry being downgraded anywhere?

No, but it is being converted to radians and then multiplied by pi

Any ideas @tiemvanderdeure ?

Thanks for pointing this out. I don't know exactly but it seems like something is being rounded somewhere?
Anyway, it's been on my list for a little while to make a specialised implementation for lon-lat grids that calculates the size of each latitudinal band in a grid and then divides it up between the cells. That should be much faster and avoids this type of error.
The current implementation just treats each cell as a linearring, which makes it super generic but slow and (apparently) introduces some precision issues.

Hmm, could that also apply to any CRS that can map to lat/long?

Yes we should be able to do the conversion for any grid aligned crs

specialised implementation for lon-lat grids that calculates the size of each latitudinal band in a grid and then divides it up between the cells

Could that also apply to any CRS that can map to lat/long via mapcrs?

It depends on this line, which (I think) should return true for any lat/long crs: https://github.com/rafaqz/Rasters.jl/blob/8d13c1887f90444d24e3c19ecbff42c8d5f0de68/ext/RastersArchGDALExt/cellsize.jl#L57
But there may be a better way to test this?

MlFor mappedcrs we test if changing the projection of two points with the same X and different Y gets points with the same X. But then the user has specified the conversion explicitly and we are just checking it's not really wrong, so its not the same situation.

Okay, I've never used mappedcrs and don't think I've ever seen it in the wild, so just trying to wrap my head around this.

For mappedcrs we test if changing the projection of two points with the same X and different Y gets points with the same X.

Are there ever cases where that holds for two projections with a different CoordSys?
I know that there are some projections which use lat/lon but are shifted/rotated compared to EPSG:4326, but I think all of those have Earth Projection 1. My thinking was that, since we're assuming the world is spherical anyway, we don't need to do any reprojecting in those cases.

I don't really know CoordSys well. But I imagine yes? Grid aligned can be converted to another with independent transformations of X and Y. So e.g. a cylindrical equal area projection can be converted to lat/lon by independently transforming it's xs and ys. In lat/lon X will have regular steps, Y will be irregular.
But it means you can use the same math you are using for lat/lon after the transformation.

I don't really know CoordSys well.

I don't either and I can't really find much about it, so if you know a better check I'd be happy.
So basically we can just check if the mappedcrs is lon-lat and if it reproject the lookups and calculate the cellsize for those. That makes sense to me.

Yeah. There is probably a more correct way... We need Julia crs parsers that give you more useful information more easily.

So e.g. a cylindrical equal area projection can be converted to lat/lon by independently transforming it's xs and ys.

Do you have an example of a raster like this, so I can add a test? I can't find any in the docs.

You can resample to it?

I just came across https://github.com/google/s2geometry/issues/190, it seems pretty insightful - maybe we should use one of the approaches there, or convert early to completely spherical (x, y, z) Cartesian points?

With the PR, this works correctly for lat/long.  But if I resample the last example raster to web mercator, I get this:

I just came across google/s2geometry#190, it seems pretty insightful - maybe we should use one of the approaches there, or convert early to completely spherical (x, y, z) Cartesian points?

But even in that thread they mention their fallback is Girard's theorem, which is exactly what we use.
In this blogpost: https://www.johndcook.com/blog/2021/11/29/area-of-spherical-triangle/, Erikson's formula was basically equal to the estimate using just planar geometry for the area between some cities in Texas: "The triangle is so flat that numerical error has a bigger effect than the curvature of the earth." And here we're talking about the error that becomes relevant when gridcells are well below 1 km^2.
We actually already test for an equal-area projection with grid spacing of 100x100m (the test is if all grid cells are within 1% of 0.1 km^2).
My vote is for assuming flat space whenever grid cells get much smaller than that and just using the haversine formula.

With the PR, this works correctly for lat/long. But if I resample the last example raster to web mercator, I get this:
Could you copy the code?

Okay thinking about this some more, I'm not sure if the Haversine formula is numerically stable at this grid spacing either. It also involves a bunch of square roots and sin and cos

Did some more testing and I can report back that

yes, this is a numeric stability issue
yes, Eriksson's formula performs better in this particular example

I did this:
xb = (166.0, 166.0006)
yb = (-78.0, -78.0003)

ring = GI.LinearRing([
    (xb[1], yb[1]),
    (xb[2], yb[1]),
    (xb[2], yb[2]),
    (xb[1], yb[2]),
    (xb[1], yb[1])
])

ring_bf = map(p -> BigFloat.(p), ring)

eriksson(GI.LinearRing(ring))
_linearring_area(GI.LinearRing(ring); radius = 1)

eriksson(GI.LinearRing(ring_bf))
_linearring_area(GI.LinearRing(ring_bf); radius = 1)

which returns
julia> eriksson(GI.LinearRing(ring))
1.1399895306967292e-11

julia> _linearring_area(GI.LinearRing(ring); radius = 1)
2.2859936166241823e-11

julia> eriksson(GI.LinearRing(ring_bf))
1.139989369278327047449715369542151261981068071545916771493908664977035933833957e-11

julia> _linearring_area(GI.LinearRing(ring_bf); radius = 1)
1.140013862214309994513259890860796762002232266534835233057189872420615878310853e-11

So: when we use big floats both methods return the same answer, and this answer corresponds to what Eriksson's formula returns using Float64.
I implemented Eriksson's formula like this. It has all these dot products and cross products so I think it's going to allocate no matter what.
function eriksson(ring)
    points = GI.getpoint(ring)
    cartesian_points = lonlat_to_cartesian.(points)
    area = 0.0
    area += eriksson_triangle(cartesian_points[1], cartesian_points[2], cartesian_points[3])
    area += eriksson_triangle(cartesian_points[3], cartesian_points[4], cartesian_points[1])
    return area
end

function eriksson_triangle(a, b, c)
    t = abs(dot(a, cross(b, c)))
    t /= 1 + dot(b,c) + dot(c, a) + dot(a, b)

    # alternative that could be more precise but allocates more
    # t = abs(dot(a, (cross(b .- a, c .- a))) / dot(b .+ a, c .+ a))

    2*atan(t)
end

lonlat_to_cartesian(args) = lonlat_to_cartesian(args...)
function lonlat_to_cartesian(lon, lat)
    x = cosd(lat) * cosd(lon)
    y = cosd(lat) * sind(lon)
    z = sind(lat)
    return [x, y, z]
end

I implemented Eriksson's formula like this. It has all these dot products and cross products so I think it's going to allocate no matter what.

I usually use static vectors or tuples to get around that, you could probably try that, but it's a pretty heavy dependency.

Yes or we can define a _dot and _cross that work on tuples of size 3 :)

Here's a super basic implementation that should get you what you need:
using LinearAlgebra

struct SphericalPoint{T <: Real}
	data::NTuple{T, 3}
end

SphericalPoint(x, y, z) = SphericalPoint((x, y, z))

# define the 4 basic mathematical operators elementwise on the data tuple
Base.:+(p::SphericalPoint, q::SphericalPoint) = SphericalPoint(p.data .+ q.data)
Base.:-(p::SphericalPoint, q::SphericalPoint) = SphericalPoint(p.data .- q.data)
Base.:*(p::SphericalPoint, q::SphericalPoint) = SphericalPoint(p.data .* q.data)
Base.:/(p::SphericalPoint, q::SphericalPoint) = SphericalPoint(p.data ./ q.data)
# Define sum on a SphericalPoint to sum across its data
Base.sum(p::SphericalPoint) = sum(p.data)

# define dot and cross products
LinearAlgebra.dot(p::SphericalPoint, q::SphericalPoint) = sum(p * q)
function LinearAlgebra.cross(a::SphericalPoint, b::SphericalPoint)
	a1, a2, a3 = a
    b1, b2, b3 = b
	SphericalPoint((a2*b3-a3*b2, a3*b1-a1*b3, a1*b2-a2*b1))
end

okay let me benchmark this!

Hmm, curious why there's still an allocation though

Hmm, curious why there's still an allocation though

because of this line, which isn't so hard to get rid of.

    cartesian_points = lonlat_to_cartesian.(points)

Also just reading back in https://github.com/google/s2geometry/issues/190, and the reason they cite for needing to keep Girard's Theorem around is for points that are antipodal, which I don't think is ever going to happen with a Raster, so I think we can safely go for the option to just always use Eriksson's formula

I now implemented this in the same PR: https://github.com/rafaqz/Rasters.jl/pull/768
Let's continue the discussion there.

Switching cellsize to use Proj.jl instead of ArchGDAL gives us a 3x speedup in the spherical case, there's also a lot of low hanging fruit.  (Just to keep the thread updated)

This can be closed now.

authors: alex-s-gardner asinghvi17 rafaqz tiemvanderdeure


text:
Feature/dapp prevent to load version directly from server

Thank you for submitting this pull request :)
Fixes #3024
Short description
Checkout the issue and the commit messages for details.
Definition of Done

[x] Steps to manually test the change have been documented
[x] Acceptance criteria are met
[ ] Change has been manually tested by the reviewer (dApp)

Steps to manually test the change (dApp)

Build productive version of the dApp for current version (yarn build)
Service build locally (e.g. npx serve ./dist)
Ensure the browser has no data on the now served location (in Chrome use dev-tools application, Clear Site Data)
Load current version of the local dApp and wait for it to install
Adapt the version to a higher number in package.json (e.g. 3.0.0)
Rebuild the dApp (yarn build)
Force-reload the dApp in the browser (Shift + F5 in Chrome)
Ensure that the dApp became temporally blocked (looks a bit squishy)
Ensure that the dApp has reloaded itself again
Ensure the dApp now shows a version update and the loaded version is the "old" one (at the bottom of the account screen)

I targeted all review comments with fixup commits. I'm confident about them, so I go ahead and resolve them. Then we have a state we can be subject of some final practical tests before we merge.

Sorry, for the linting mistake. Rooky mistake...

We made a more production realistic test. And we discovered an issue. I made a mistake an forgot that service workers must be able to understand messages of the old application and send messages to the old application and new one understands them. This is a complex issue.

Because I haven't worked with schema versioning for a while I read this book tonight to recap a little. The used approach is explained in much detail within the related commit message. Please check it out.
I made the tests that failed yesterday locally and forced a new service worker version to work with the old client (v1.0.0). It works as expected. It can detect a broken cache and also an update is possible to the new version. The same goes for the new version of both components.

Andre made the suggestion that we can also protect all versions before the new release. We planned the design and I'm implementing it.

Our production close tests worked very well. We even made some last UI improvements. Waiting for CI now.

source: gharchive/pull-request

repo: raiden-network/light-client


text:
What can go wrong if the user-provided token network answers different channel_ids for each call

MonitoringService.monitor() calls token_network.getChannelIdentifier() twice.

first in updateRewards() function
second in the body of monitor() function

This issue investigates what happens if the caller gives a malicious token network address that returns different answers to those getChannelIdentifier() calls.

The first channel identifier is compared with the channel identifier in the IOU.
The second channel identifier is used to calculate the priority of the MonitoringService.
So an attacker can get an unreasonably early monitoring spot.
This doesn't matter when on a reasonable TokenNetwork.

However, monitoring services on a reasonable TokenNetwork and the attacker on a wrong TokenNetwork share the same pool of user deposits.  So this path should be probably mitigated.

repo: raiden-network/raiden-contracts


text:
Create pipeline

Subj

Implemented:

Lints and tests
Semantic release
Publish to pypi
Bump, build and push helm charts after semantic-relese
Build docker images on tags


text:
InsertManager#insert doesn't return self, not allowing it to be chainable

Seems like most methods on these Managers are chainable but oddly this one isn't?

@krainboltgreene many other managers, or other methods from this manager don't return self as well(some are setters). Whats the use case you would like this to return self.

@vipulnsward Is that actually true? Here's the methods that are chainable:

SelectManager#skip, SelectManager#lock, SelectManager#on, SelectManager#group, SelectManager#from, SelectManager#join, SelectManager#outer_join, SelectManager#having, SelectManager#project, SelectManager#distict, SelectManager#distinct_on, SelectManager#order, SelectManager#with, SelectManager#take,
UpdateManager#take, UpdateManager#order, UpdateManager#table, UpdateManager#where, UpdateManager#set
InsertManager#into
DeleteManager#take, DeleteManager#from

I mean it seems like it should chain, in the same way UpdateManager#set chains.
table = Arel::Table.new(:persons)
query = table.where(table[:id] => 1).set(table[:name] => "Kurtis")
string = query.sql

table = Arel::Table.new(:persons)
query = table.insert(table[:name] => "Kurtis")
string = query.to_sql

Instead I have to write (for no discernible reason):
table = Arel::Table.new(:persons)
query = table.tap { |t| t.insert(table[:name] => "Kurtis") }
string = query.to_sql

Fixed on master.

repo: rails/arel

license: mit

license_source: bigquery


text:
Issue running bin/dev when creating new project rails new project --css tailwind

➜  depot git:(main) ✗ bin/dev
09:25:48 web.1  | started with pid 6454
09:25:48 css.1  | started with pid 6455
09:25:48 css.1  | /Users/kevon/.rbenv/versions/3.1.2/lib/ruby/site_ruby/3.1.0/bundler/definition.rb:498:in `materialize': Could not find importmap-rails-1.1.5, turbo-rails-1.1.1, stimulus-rails-1.1.0, tailwindcss-rails-2.0.10-arm64-darwin, bootsnap-1.13.0, msgpack-1.5.4, strscan-3.0.4 in any of the sources (Bundler::GemNotFound)
09:25:48 css.1  |       from /Users/kevon/.rbenv/versions/3.1.2/lib/ruby/site_ruby/3.1.0/bundler/definition.rb:191:in `specs'
09:25:48 css.1  |       from /Users/kevon/.rbenv/versions/3.1.2/lib/ruby/site_ruby/3.1.0/bundler/definition.rb:247:in `specs_for'
09:25:48 css.1  |       from /Users/kevon/.rbenv/versions/3.1.2/lib/ruby/site_ruby/3.1.0/bundler/runtime.rb:18:in `setup'
09:25:48 css.1  |       from /Users/kevon/.rbenv/versions/3.1.2/lib/ruby/site_ruby/3.1.0/bundler.rb:162:in `setup'
09:25:48 css.1  |       from /Users/kevon/.rbenv/versions/3.1.2/lib/ruby/site_ruby/3.1.0/bundler/setup.rb:20:in `block in <top (required)>'
09:25:48 css.1  |       from /Users/kevon/.rbenv/versions/3.1.2/lib/ruby/site_ruby/3.1.0/bundler/ui/shell.rb:136:in `with_level'
09:25:48 css.1  |       from /Users/kevon/.rbenv/versions/3.1.2/lib/ruby/site_ruby/3.1.0/bundler/ui/shell.rb:88:in `silence'
09:25:48 css.1  |       from /Users/kevon/.rbenv/versions/3.1.2/lib/ruby/site_ruby/3.1.0/bundler/setup.rb:20:in `<top (required)>'
09:25:48 css.1  |       from <internal:/Users/kevon/.rbenv/versions/3.1.2/lib/ruby/site_ruby/3.1.0/rubygems/core_ext/kernel_require.rb>:85:in `require'
09:25:48 css.1  |       from <internal:/Users/kevon/.rbenv/versions/3.1.2/lib/ruby/site_ruby/3.1.0/rubygems/core_ext/kernel_require.rb>:85:in `require'
09:25:48 web.1  | /Users/kevon/.rbenv/versions/3.1.2/lib/ruby/site_ruby/3.1.0/bundler/definition.rb:498:in `materialize': Could not find importmap-rails-1.1.5, turbo-rails-1.1.1, stimulus-rails-1.1.0, tailwindcss-rails-2.0.10-arm64-darwin, bootsnap-1.13.0, msgpack-1.5.4, strscan-3.0.4 in any of the sources (Bundler::GemNotFound)
09:25:48 css.1  |       from /Users/kevon/Documents/projects/ruby/depot/config/boot.rb:3:in `<top (required)>'
09:25:48 web.1  |       from /Users/kevon/.rbenv/versions/3.1.2/lib/ruby/site_ruby/3.1.0/bundler/definition.rb:191:in `specs'
09:25:48 css.1  |       from bin/rails:3:in `require_relative'
09:25:48 web.1  |       from /Users/kevon/.rbenv/versions/3.1.2/lib/ruby/site_ruby/3.1.0/bundler/definition.rb:247:in `specs_for'
09:25:48 css.1  |       from bin/rails:3:in `<main>'
09:25:48 web.1  |       from /Users/kevon/.rbenv/versions/3.1.2/lib/ruby/site_ruby/3.1.0/bundler/runtime.rb:18:in `setup'
09:25:48 web.1  |       from /Users/kevon/.rbenv/versions/3.1.2/lib/ruby/site_ruby/3.1.0/bundler.rb:162:in `setup'
09:25:48 web.1  |       from /Users/kevon/.rbenv/versions/3.1.2/lib/ruby/site_ruby/3.1.0/bundler/setup.rb:20:in `block in <top (required)>'
09:25:48 web.1  |       from /Users/kevon/.rbenv/versions/3.1.2/lib/ruby/site_ruby/3.1.0/bundler/ui/shell.rb:136:in `with_level'
09:25:48 web.1  |       from /Users/kevon/.rbenv/versions/3.1.2/lib/ruby/site_ruby/3.1.0/bundler/ui/shell.rb:88:in `silence'
09:25:48 web.1  |       from /Users/kevon/.rbenv/versions/3.1.2/lib/ruby/site_ruby/3.1.0/bundler/setup.rb:20:in `<top (required)>'
09:25:48 web.1  |       from <internal:/Users/kevon/.rbenv/versions/3.1.2/lib/ruby/site_ruby/3.1.0/rubygems/core_ext/kernel_require.rb>:85:in `require'
09:25:48 web.1  |       from <internal:/Users/kevon/.rbenv/versions/3.1.2/lib/ruby/site_ruby/3.1.0/rubygems/core_ext/kernel_require.rb>:85:in `require'
09:25:48 web.1  |       from /Users/kevon/Documents/projects/ruby/depot/config/boot.rb:3:in `<top (required)>'
09:25:48 web.1  |       from bin/rails:3:in `require_relative'
09:25:48 web.1  |       from bin/rails:3:in `<main>'
09:25:49 css.1  | exited with code 1
09:25:49 system | sending SIGTERM to all processes
09:25:49 web.1  | exited with code 1

Hi! I'm sorry you're having this problem.
Unfortunately, I can't reproduce what you're seeing. It looks like you may not have all the necessary gems installed, so I would recommend running bundle install in case that's the cause.
If that doesn't resolve your issue, please respond with a comment that shows:

the output of bundle env
the output from your rails new command

Thank you!

authors: flavorjones kevincf

repo: rails/tailwindcss-rails


text:
Log fixes

The log files are using a relative path and are causing problems. This PR fixes that and changes the file type from .txt to .log.

Looks good.

authors: MFRWDesign ericsaupe


text:
Start working on faster CI

Resolves #132

This has shaved about 2 minutes off of the amount of time it typically takes to execute tests.

I believe we had Docker caching but it was removed because it was taking up too much space. Any ideas on how we can bring that back?

repo: railwayapp/nixpacks


text:
Decoding error on license file on macOS

Same issue as #35 and #37 but on macOS with a standard Python 3 install, not in a docker container.
Tested on 1.16.1.
$ pip-licenses --from=mixed --with-system --format=rst --with-license-file
Traceback (most recent call last):
  File "/Users/user/proj/.tox/licenses/bin/pip-licenses", line 8, in <module>
    sys.exit(main())
  File "/Users/user/proj/.tox/licenses/site-packages/piplicenses.py", line 638, in main
    print(output_string)
  File "/Users/user/proj/.tox/licenses/lib-python/3/encodings/ascii.py", line 22, in encode
    return codecs.ascii_encode(input, self.errors)[0]
UnicodeEncodeError: 'ascii' codec can't encode character '\xa9' in position 167881: ordinal not in range(128)

Python prompt for reference:
$ python
Python 3.6.9 (5da45ced70e5, Oct 09 2019, 19:13:07)
[PyPy 7.2.0 with GCC 4.2.1 Compatible Apple LLVM 10.0.0 (clang-1000.11.45.5)] on darwin
Type "help", "copyright", "credits" or "license" for more information.

The package whose license file is failing is Pillow == 6.2.1

Thanks for the report. I also try it on my macOS.

@jameslamb It didn't reproduce on my macOS.
However, it was reproduced when executed as follows.
# raise Same error you reported 'UnicodeEncodeError'
$ env LANG=US-ASCII LC_CTYPE=US-ASCII pip-licenses --from=mixed --with-system --format=rst --with-license-file

From this fact, I am suspicious of LANG and LC_CTYPE of tox environment.
Write passenv in your tox.ini file and run it again.
[testenv]
passenv= LANG LC_CTYPE

[testenv]
passenv= LC_CTYPE

fixed it, thanks!
Still strange though. I suppose that it's because tox doesn't bring in any ENV variables by default. But, then again lots of Python programs can read Unicode files from within tox, so I wonder if there is a way to make pip-licenses work out of the box? It seems like if it's reading arbitrary license files from PyPI it shouldn't really need to assume the user has a certain locale.
Hmm, not sure, but really appreciate the fix!

I add to the documentation as a frequently asked question about UnicodeEncodeError.
Your report was very helpful. Thanks a lot!

[!IMPORTANT]
Starting with PEP 263 in 2001, UTF-8 replaces
ascii as the default, providing strong historical support for expecting UTF-8.
Further, after this issue was resolved, PEP-686
has standardized this in relation to the open function's default, making the fix here
no longer even necessary.
TL;DR My rational for commenting on a closed issue is: this issue is referenced in the
pip-licenses documentation, and the general confusion of the discussion here about
defaulting to UTF-8 as an encoding. I hope this helps someone in the future.

[!NOTE]
This variation of #35 is related to PEP 597

authors: johnthagen raimon49 reactive-firewall


text:
🛑 RiotSkin4CN-Download is down

In 3471218, RiotSkin4CN-Download (https://s-cd-4307-general.oss.dogecdn.com/riotskin4cn/live.json) was down:

HTTP code: 0
Response time: 0 ms

Resolved: RiotSkin4CN-Download is back up in acd6412.


text:
Broken API Rate Limiting Handler and Exception Handler

Describe the bug

Replicon Handler attempts to get the Execution Correlation ID from the Response Headers of each call it made.
Rate limiting response from Replicon API does not including x-execution-correlation-id in the Response Headers.
Rate limited calls made by Replicon Handler to the Replicon API are raising a KeyError, pushing the handler into a retry loop.

Issues Observed

Replicon APIs Rate Limiting Responses are not handled properly.
Any exception is pushing the Replicon Handler into a retry loop.

Affected Release(s)

1.1.7 and lower.

Steps to Reproduce

Make enough calls to the Replicon API from an instance to trigger the rate limiting phase.
Trigger any Python exception, and the Replicon Handler will run into a retry loop.

Expected behavior
Rate Limiting Handler

When calls to the Replicon API are rate limited, the handler should pause till the rate limiting time passes.
The call which was rate limited and the following should be retried after the handler unpauses.

Exception Handler

Not all the exceptions should kick the handler into a retry loop.
Network related and SSL related exceptions should be retried.

This was fixed a long time ago, but the fix wasn't deployed to PyPI as a new release because I couldn't find the time. The fix is in the development branch.

repo: rajakodumuri/replicon-handler


text:
Fixed the issue - #31

Hey @rajivharlalka ,
Fixed issue - Impressive & Informative Project Readme #31
Checkout the changes I have made and if you want to me to add more things in that, Let me know ..................
and if everything is good to go , Kindly merge it .
You can see the Output here, Checkout here
https://github.com/ayush-sleeping/Accio

Thanks @ayush-sleeping for the PR, the Readme looks nice now. Just a small change that would be good. in the Open Source programs the repo has been a part of  instead of Kharagpur Open Source Society it Would be Kharagpur Winter of Code and it's logo. The link is fine as it redirects to kwoc's website.

LGTM , any suggestions from your side @chirag828049 ?

Awesome work.
Just a little nitpicking. The spelling of "repository" is wrong.
Everything else great. Fix that, I'll merge the PR.
Thanks.

Awesome work. Just a little nitpicking. The spelling of "repository" is wrong. Everything else great. Fix that, I'll merge the PR. Thanks.

thanks for noticing, I fixed the part . Checkout ......

Great!

repo: rajivharlalka/Accio


text:
Workaround - cannot parse clusterNetworkPrefix and endpointMacPrefix

NOTE: This pull request is not a fix itself, as I am not a Go programmer. So it is only a workaround, but it points out an issue that could be fixed in a go-ish way.
I have noticed that in case of l2bridge plugin clusterNetworkPrefix does not get unmarshalled and endpoint hns policies have "" when using IPMasq. Same goes for endpointMacPrefix.
This behaviour is caused by lower-/upper-case and json unmarshalling https://stackoverflow.com/questions/28228393/json-unmarshal-returning-blank-structure. After simple change of the field names to upper case, there are problems with unmarshalling raw string to net.IPNet, so I have changed this to a raw string as a workaround.

@calory, true, as we talked on Slack, this creates problems with intra pod communication, looks like outbound NAT exceptions are not working properly :( so this pull request does not make much sense for now, I will leave it only for "demo" purposes and other changes in json unmarshalling.
BTW I will be off for a few weeks, we will see what happens when I am back, maybe everything gets fixed ;)

repo: rakelkar/plugins


text:
A method to directly read the document by it's _id

Right now to find a document by it's _id the system will go through all the checks it has to fetch data from documents.
As the file name of a document is identical to its _id and as this id will be auto generated by the system so I think it's safe and efficient to have a method findById which will directly read a json file of that store and return the data instead of going through all the steps.

Sounds awesome!

Will be done with #75

Will be done with #75

repo: rakibtg/SleekDB


text:
Ensure fork versions and fork epochs are updated for preconfigured networks

Ensure *_FORK_VERSION and *_FORK_EPOCH under configs::* are up to date with the latest values for the capella and deneb forks.
Networks/configs:

[x] mainnet
[x] holesky
[ ] goerli
[ ] sepolia
[ ] minimal

Reference configs can be found here: https://github.com/eth-clients

mainnet and holesky should have been updated correctly in #328

repo: ralexstokes/ethereum-consensus


text:
Add functionality for generating valid / random states

User Story:
As a dev, I'd like to be able to test the various functions throughout this library; however, creating dummy/test BeaconState and Context objects is not straightforward. Ideally, I'd like to be able to run tests and create these objects with something like ::random() to then write various tests on the dummy data -- e.g., helping me verify how the state transition functions are manipulating the data.
Requirements:
Add functionality, such as implementing ::random(),  for generating valid / random states on BeaconState and Context (and related subtypes)

using something in the realm of property-based testing would be great here -- ideally we want to be able to generate random values for all of our types and be able to apply constraints on the values so that we can get actual consistent instances.
for example, i know if we had such a thing we could apply it to generating more interesting spec tests for https://github.com/ethereum/consensus-specs

Before I attempt to take this on & start researching, are there any resources / guidelines off the top of your head that would help here? Just figuring out where to start -- e.g., looking at ssz_rs, would it follow a similar design by adding default impls to everything in BeaconState and Context?

i'd say implementing tests are higher priority, and then continuing on the altair and bellatrix forks, and also implementing an optimized phase0 spec
for future reference, i'd say we consider starting w/ random impls like in this example: https://rust-lang-nursery.github.io/rust-cookbook/algorithms/randomness.html#generate-random-values-of-a-custom-type using the rng crate


text:
Picking from a list by an array of indices.

Sorry if this already exists – I needed something like this today, but couldn't seem to find something that does this without using R.nth and other functions together! Would this be generally useful enough to add?
R.takeIndexed([0, 2], ['a', 'b', 'c']); // =>['a', 'c']

I'm hesitant to submit a pull request, since I don't if it's appropriate with what's wanted, what to name it, or whether there's an internal function to make this more concise 😶. But something like this would work?
var _curry2 = require('./internal/_curry2');
var _nth = require('./internal/_nth');

/**
 * Returns a new list containing the elements of xs at the specified indices.
 * If an index n is negative, the element at index length + n is returned in the corresponding slot.
 * If an index n is past the end of the array, undefined is returned in the corresponding slot.
 *
 * @func
 * @memberOf R
 * @category List
 * @sig [Number] -> [a] -> [a]
 * @param {Array} indices An array of indices used to pull elements into the new list
 * @param {Array} xs The list to pull elements from
 * @return {Array} A new list with only elements from the specified indices.
 * @example
 *
 *      R.takeIndexed([0, 2], ['foo', 'bar', 'baz']); // => ['foo', 'baz']
 *      R.takeIndexed([-1, 0], ['foo', 'bar', 'baz']); // => ['baz', 'foo']
 *      R.takeIndexed([0, 3], ['foo', 'bar', 'baz']); // => ['foo', undefined]
 */
module.exports = _curry2(function takeIndexed(indices, xs) {
  var result = [];
  var idx = -1;
  while (++idx < indices.length) {
    result[idx] = _nth(indices[idx], xs);
  }
  return result;
});

takeIndexes might be a better name. The ...Indexed naming has other semantics.

R.compose(R.values, R.pickAll);

Ah, I didn't know R.pickAll would work on lists as well. Perhaps the documentation should be updated to reflect that? I tried pick at first, which didn't work, so I assumed R.pickAll wouldn't.
In that case, there is a difference between R.pickAll and R.pick when working on lists:
R.pick([0, 2], ['a', 'b', 'c'])
Object {0: "a"}

R.pick([0, 2], ['a', 'b', 'c'])
Object {0: "a"}

Also, the order of R.compose(R.values, R.pickAll) is also not guaranteed to be the order of the input array of indices, which is undesirable, so there might still be a case for a List specific method.

In that case, there is a difference between R.pickAll and R.pick when working on lists:

Right, discussed in #1121.  This should be fixed soon.

the key iteration order is still a valid issue though. if you are very convcerned about that case you could do something like
function pickIdx(ids, list) {
  return R.filterIndexed(function(_, idx) {
    return R.contains(idx, ids);
  }, list);
}

pickIdx([0, 2], ['a', 'b', 'c']); //=> ['a', 'c']

i could probably do this as a one-liner using ap ....

ap(map(nth, [0, 1]), of(['a', 'b', 'c']))

@raine nice! very similar use case to a blog post i did on using ap and of

(add it to the cookbook!)

Another solution:
R.map(R.nth(R.__, ['a', 'b', 'c']), [0, 2])

Agreed that it can be written using other functions, it can just take a little time to parse what's going on from a readability standpoint. I think there's still the case that it might be a fairly basic piece of functionality that an engineer could want! Anyways, I will let you guys decide :), and use ap for now.

my feeling is we should not expand the api with functions that can easily be composed except when there is a compelling reason to do so. i'm interested to hear other opinions.

I agree.  Compelling reasons might include that such a function would be really common (pipe versus compose) or where this allows us to expose very well-known names (unary, binary.)

+1 for implementing this as a separate function for readability, I think this is a pretty common operation

I'm surprised nobody mentioned props yet.
props([0, 2], ['a', 'b', 'c']); // => ['a', 'c']

authors: 3limin4t0r CrossEye buzzdecafe davidchambers josephong raine rmarren1

repo: ramda/ramda


text:
PHPStan fails for the current codebase

Description
PHPStan reports errors when run manually or during a CI run. I saw this first when working on #58 but then I reproduced this on the main branch as well. That is the reason I am creating a new issue and a PR.
Steps to reproduce

Make sure you are on the latest dependencies with composer update
Run composer dev:analyze:phpstan

Expected behavior
We should see a message from PHPStan saying [OK] No errors.
Screenshots or output
See output below or on one of the recent CI runs.
❯ composer dev:analyze:phpstan
> phpstan analyse --ansi
Note: Using configuration file /Users/hw/work/php/conventional-commits/phpstan.neon.dist.
 96/96 [▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓] 100%

 ------ ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
  Line   src/ConventionalCommits/Configuration/DefaultConfiguration.php
 ------ ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
  88     Offset 'bodyWrapWidth' on array{typeCase?: string|null, types?: array<string>, scopeRequired?: bool, scopeCase?: string|null, scopes?: array<string>, descriptionCase?: string|null, descriptionEndMark?: string|null,
         bodyRequired?: bool, ...} on left side of ?? always exists and is not nullable.
 ------ ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

 ------ -----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
  Line   tests/ConventionalCommits/Configuration/DefaultConfigurationTest.php
 ------ -----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
  38     Call to method PHPUnit\Framework\Assert::assertSame() with array{typeCase: null, types: array{}, scopeCase: null, scopeRequired: false, scopes: array{}, descriptionCase: null, descriptionEndMark: null, bodyRequired:
         false, ...} and array{typeCase?: string|null, types?: array<string>, scopeRequired?: bool, scopeCase?: string|null, scopes?: array<string>, descriptionCase?: string|null, descriptionEndMark?: string|null, bodyRequired?:
         bool, ...} will always evaluate to false.
  88     Call to method PHPUnit\Framework\Assert::assertSame() with array{typeCase: 'kebab', types: array{'foo', 'bar', 'baz-qux'}, scopeCase: 'lower', scopeRequired: true, scopes: array{'component', 'unit', 'foo'},
         descriptionCase: 'sentence', descriptionEndMark: '.', bodyRequired: true, ...} and array{typeCase?: string|null, types?: array<string>, scopeRequired?: bool, scopeCase?: string|null, scopes?: array<string>,
         descriptionCase?: string|null, descriptionEndMark?: string|null, bodyRequired?: bool, ...} will always evaluate to false.
 ------ -----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

Environment details

version of this package: main
PHP version: 8.1.10
OS: macOS

Additional context
None

Fixed in #64

authors: hussainweb ramsey

repo: ramsey/conventional-commits


text:
Backup & Restore creation page UI tooltip and header name change

Can we rename this header to "Storage Location"?

Since we no longer show the ResourceSet in UI, can we change this tooltip to:

Delete the resources and CRDs managed by Rancher that are not present in the backup. (Recommended)

Verified on master-head, header is changed

Tooltip is updated

repo: rancher/dashboard


text:
Mount point field not appearing on the workload creation form

Setup

Rancher version: v2.6.9
Browser type & version: Chrome

Describe the bug
There is no option to enter mount point when creating deployment/statefulSet and attaching a volume to it.
To Reproduce

Go to Rancher Dashboard, navigate to the Deployments. Click Create.
Go to Pod--> Storage
Add volume using Create Persistent volume claim.

Result
4. There is no option to enter the mount point.
Expected Result
There should be a field to enter the mount path and subpath.
Screenshots

Additional context
It was available in previous versions.

Do you see it under the container tab?

This should be expected behavior because the storage volume is configured at the pod scope, but the mount point is configured at the container scope (because the volume can be mounted at different paths for different containers). The mount path was removed from the pod tab because it had to move to the container tab.

Yeah, that was what I was confusing in the older Rancher version since it doesn't make sense to have mount point at pod level

Mount paths for containers are in containers tab as per 2.6.9
Change PR: https://github.com/rancher/dashboard/pull/6886

Validated that the mount point is now available in the container tab.

authors: PhanLe1010 Shavindra catherineluse khushboo-rancher


text:
Logging V2 CRDS

https://banzaicloud.com/docs/one-eye/logging-operator/crds/
For logging v2 a single page will be needed to create / update flows and outputs.  For the flow configuration section users will need to select a namespace. For the output section users will need to be able to configure one or more outputs.  The outputs can be different types and will require different forms.  See https://github.com/rancher/dev-charts/blob/master/packages/rancher-logging/rancher-logging.patch for outputs and fields.

Misunderstood the requirements for this issue.  Closing to create a more effective ticket.


text:
[2.5.8] Update zh-hans.yaml

fixed tons of duplicate keys and other YAML errors in @#2822 and @#2799
update CN contents in zh-hans.yaml

wrong base, see https://github.com/rancher/dashboard/pull/2828 for update


text:
Only read yaml files included in the given directories

Signed-off-by: David Cassany dcassany@suse.com

I found this while trying to document a couple of different procedures to install extra packages in the scope of rancher/elemental#334 elemental-register was trying to read any yaml found in the given directories and any subdirectory too, however the path of subdirectories was not included as a config dir in viper. Current se only checks for yaml in given directories, no subdirectories.
Note this only to read registration yaml, so it doesn't make much sense a setup where the data is split into multiple files in some sort of conf.d subdirectory, hence omitting the subdirectories should be absolutely fine. Also the issue appeared because we pass the ISO root to the elemental-register as an argument, hence the complete directory tree was parsed.

repo: rancher/elemental-operator


text:
Add "meta-data" to userDataFiles string list Refers #2125

As suggested in the issue I've raised, this allows cloud-init on toolkit built images to pick up cloud config in files named "meta-data" such as the one Harvester provides instance data in.

It has occurred to me that perhaps this change is better made upstream here: https://github.com/rancher-sandbox/linuxkit/blob/main/providers/provider_cdrom.go ?

Thanks @davidcassany that sounds good. I've opened https://github.com/rancher-sandbox/linuxkit/pull/5 and am closing this PR.

repo: rancher/elemental-toolkit


text:
k3os.install.power_off is listed twice in auto installation documentation

Version - v0.2.0
Steps:

Go to automatic installation section of the documentation on rancher/k3os

Results:  power_off is in twice

Verified


text:
Add rng-tools

Use hw rng devices for entropy if found.

Not completely sure if this will conflict with haveged in any way.

@zimme you probably want to also add rng-tools-openrc and modify the overlay/libexec/boot script to use rngd instead of haveged.
is it your intention to replace haveged with rngd or just have both present? they both provide the same entropy openrc service.

The intention was to use rng-tools for devices that have hardware rng devices like the rpi's from rpi2 or 3 and above. And for devices or vms that don't have hw rng use haveged instead.

From what I've read so far it seems as though rng-tools will setup and use /dev/hwrandom or /dev/hwrng if available and if it's not available do nothing. That leads me to believe once could use rng-tools and haveged together.

Included with #292

authors: dweomer zimme


text:
[Documentation] Uninstall docs needs to include killall script

Needs documentation for k3s-killall.sh
After uninstall, executing k3s-killall.sh restores iptables and cleans up logs.

@davidnuzik - if run killall can just run k3s again? needs install again? (if restores iptables how would k3s work properly post killall script?

Was able to confirm with Shylaja you can just start K3s again and it will work correctly.

Closing this issue because https://github.com/rancher/docs/pull/2507 was merged

Closing will look into permissions for Catherine tomorrow