Track finality

[volovyks]

No description provided.

[volovyks]

@ChaoticTempest I've added LATEST_BLOCK_NUMBER status=processed to set_processed_block() function, but it is called when we index the block, not when we respond to all the requests from it. I will dig into it, but happy to get some advice.

[volovyks]

@ChaoticTempest I've added LATEST_BLOCK_NUMBER status=processed to set_processed_block() function, but it is called when we index the block, not when we respond to all the requests from it. I will dig into it, but happy to get some advice.

I see that my concept of processed block does not correspond to processed on the Backlog layer, where it is more of an "added to backlog", not "all requests got a response".

I

[ppca]

Is it better to add processed block number metric in process_respond_events() and process_respond_bidirectional_events()? A respond event is the actual evidence of a signature being published.

[volovyks]

@ppca, from what I see, process_respond_events sends requests to the sign queue, which allows us to track finalized block height. This PR is tracking that from refresh_finalized_block, is that correct?
As of "processed", as I've said, there is no such thing in our system as a processed block (all requests from that block got a response).

[volovyks]

@ppca @ChaoticTempest I've removed "processed" status from LATEST_BLOCK_NUMBER, it does not make sense in the current architecture. We may get back to this later. Let's merge "finalized" status for now.