protocolParams returning null

[CyberCyclone]

Running Git commit 6f20487

Platform

• Linux / Ubuntu
• Linux / Other
• macOS
• Windows

Platform version:

Runtime

• Node.js
• Docker

Steps to reproduce the bug

Something "interesting" has happened with the epoch change over. The protocolParams in the epoch for 231 is empty. This bug seems to be similar to what has caused #375.

This occurred at the moment of the epoch change over:

Running this command usually pulls this epochs stats but as you can see it's null:

{
  cardano {
    tip { 
      hash 
      slotNo
      slotInEpoch
      number
      forgedAt
      epochNo 
      epoch { 
        protocolParams {
          a0
          decentralisationParam
          nOpt
          rho
          tau
        }
      }
    }
  }
}

Next Steps

I'm currently doing a full db and cardano-node rebuild on another server to see if it does anything.

[CyberCyclone]

This fixes itself after a full DB and node re-sync.

[rhyslbw]

This fixes itself after a full DB and node re-sync.

When checking the rebuilt instance, was 231 still the current epoch ?

[CyberCyclone]

Yes, at that point it was still 231. From what I've seen, transitioning from 230 to 231 wasn't populating the records (protocolParams and activeStake) for 231 but I could still lookup records in 230. This only happened when the node was running live during the epoch transition. When doing a DB rebuild, the data is then populated for epoch 231 while 231 was the current active epoch.

During the last transition from epoch 231 to 232 I did not have this issue and I wasn't impacted by the cardano-db-sync epoch bug at all while running the graphql 3.0.0 release.

I do notice that when running { cardanoDbMeta { initialized syncPercentage }} at the start of a new epoch, a few minutes after 'initialized' turns to 'false'. Then about 5 or 10 minutes later it then returns to 'true'.

Am I correct in understanding that at the start of an epoch, protocolParams and activeStake are calculated and then populated into the table which can cause the 'initialized' to turn to 'false' during this calculation? If this is the case, is it possible that if there's a system glitch during that time that it could cause both of these to fail and therefore not populate the tables?

[CyberCyclone]

Just an update. No issues with this bug during the epoch transition to 233.

[rhyslbw]

Thanks for the additional info @CyberCyclone.

I do notice that when running { cardanoDbMeta { initialized syncPercentage }} at the start of a new epoch, a few minutes after 'initialized' turns to 'false'. Then about 5 or 10 minutes later it then returns to 'true'.

Am I correct in understanding that at the start of an epoch, protocolParams and activeStake are calculated and then populated into the table which can cause the 'initialized' to turn to 'false' during this calculation?

cardano-db-sync must be falling behind the expected network tip performing the epoch-rollover operations. I'll be adjusting the determination of initialized in an upcoming release, as the current design is quite limited, and the intent of that property is to guard against inconsistent state on an initial build. This will also fix the syncPercentage value which you may have noticed is invalid in the Shelley-era. Follow #248 for updates on this.

... If this is the case, is it possible that if there's a system glitch during that time that it could cause both of these to fail and therefore not populate the tables?

Yes it's possible. Feel free to reopen if you think there's more to be done here.

Here's a simplified query too:

{
  cardano {
    currentEpoch {
      protocolParams {
          a0
          decentralisationParam
          nOpt
          rho
          tau
        }
    }
  }
}