I was running node v1.33 and I was using cncli leaderlog to check block generation schedule. It has been working flawlessly so far.
Recently I start to upgrade node to v1.34.1. So I set up another pool with identical credential, but without cncli, because I want to use the native “cardano-cli query leadership-schedule” instead. Today I ran leader checking on both pools, and to my surprise they don’t agree with each other. Specifically v1.33+cncli pool reports a block creation while the new v1.34.1 pool reports none.
Anybody knows why? Did I miss anything in the new pool query command? Below are the commands I used on each pool to do the query.
Use the same method (i.e., duplicating server) and checked on testnet. Both cncli leaderlog and query leadership-schedule agree with each other with many blocks being reported (and being generated since I queried current epoch)
I deleted cncli db on my production mainnet server (producer node) and re-create cncli db from scratch. This time “cncli leaderlog” qould reports no block scheduled, agreeing with “query leadership-schedule” method.
So in short “cncli” is there to blame, it seems. I will still keep the node running as it is to confirm before I switch over the standby server to take over the pool.
That is right. It is confirmed with time passing the predicated slot.
I knew it should be case when I re-created cncli db and the new db said “no”. And this is the second time that cncli mispredicted block schedule. Let us hope the new native query won’t have such mistake.
I’m letting my new server running in standby mode. Will formally switch over when I feel comfortable. While we are here, my pool is MYADA. Please take a look and consider delegating to it.