feat: fetch pox constants from stacks-core /v2/pox and store in pg #7
Conversation
…r cycle calculations
| } | ||
| await db.updatePoxInfo(rpcPoxInfo); | ||
| isDbMissingPoxInfo = false; | ||
| await sleep(POX_INFO_UPDATE_INTERVAL_MS, abortSignal); |
There was a problem hiding this comment.
This could return and end the background /v2/pox fetches, but I don't think it hurts and it can provide some possibly useful debugging data (we can see RPC connection error logs if something weird is happening later on).
There was a problem hiding this comment.
I doubt a chain can change phase lengths during operation, so probably not needed, but I don't see the problem with keeping it for logs/interest 😉
|
Vercel deployment URL: https://signer-metrics-7mvgl0u8z-hirosystems.vercel.app 🚀 |
|
🎉 This PR is included in version 0.1.0-beta.1 🎉 The release is available on GitHub release Your semantic-release bot 📦🚀 |
|
🎉 This PR is included in version 0.1.0 🎉 The release is available on GitHub release Your semantic-release bot 📦🚀 |
We need to be able to calculate pox reward cycle numbers in various areas which cannot be done reliably without knowing the pox constants
first_burnchain_block_heightandreward_cycle_length. These could be hardcoded for mainnet, but for other networks the only way to determine them is from a stacks-core RPC fetch to/v2/pox. Ideally these would be emitted from stacks-core in the future.In order to avoid race conditions where the stacks-node RPC may not be available when this service starts, this is implemented as a background job that retries indefinitely.