Moment of finality in Libra


I am having troubles understanding the precise moment of finality in Libra.
To my understanding finality occurs when at least 2f+1 nodes have committed the block.
When reading Libra’s papers and source code, as soon as block b_i has qc_j+2 it gets committed.
As there are 3 consecutive qc’s. When a client queries this node it responds positively that the transaction is final, but when querying the other nodes they respond negatively that the transaction is not final, first green vertical arrow at qc_j+2 in the graph. Only after the other nodes receive the next proposal, that includes this qc_j+2, they can commit block b_i as well(last 3 green vertical arrows). Is this not the moment of finality?

Then consider the scenario where Node 3 crashes just after forming qc_j+2 and replying to the clients request that his transaction is final. The round times out and the next leader creates a block with the highest qc is knows, which is qc_j+1 currently. It will take another 3 rounds of qc’s before b_i can be committed again, is this correct? Does this not create a inconsistent state where only node 3 knows that b_i is already committed and all the other nodes do not?

Sub questions:
Is it true that a round leader also votes on his own block?
When a node receives a proposal and also happens to be the next round leader, does he vote?

To make this situation more clear I created the figure below.

1 Like