Instead of just the confirmed block height, expose the full block metadata (the block field of the ZMQ notification) to the pending move processor. This allows it to e.g. also get a (rough) idea of what the next block time might be (at which to evaluate the pending moves).
In order to have this information, we keep an in-memory cache of the last attached blocks. Only if the last block is known based on that queue will pending moves be processed. This leads to some situations in which they will be ignored, e.g. when the node has just been started up or a long reorg has finished. But those situations will not be often in practice, and will most likely be situations in which pending moves would not be super meaningful anyway. Returning an empty set of pending moves is always a "valid" thing to do anyway, as there is no guarantee of knowing about any in the mempool anyway.
Instead of just the confirmed block height, expose the full block metadata (the
blockfield of the ZMQ notification) to the pending move processor. This allows it to e.g. also get a (rough) idea of what the next block time might be (at which to evaluate the pending moves).In order to have this information, we keep an in-memory cache of the last attached blocks. Only if the last block is known based on that queue will pending moves be processed. This leads to some situations in which they will be ignored, e.g. when the node has just been started up or a long reorg has finished. But those situations will not be often in practice, and will most likely be situations in which pending moves would not be super meaningful anyway. Returning an empty set of pending moves is always a "valid" thing to do anyway, as there is no guarantee of knowing about any in the mempool anyway.