paritytech / json-rpc-interface-spec

30 stars 3 forks source link

best-block: can be temporarily unknown? #116

Closed josepot closed 1 year ago

josepot commented 1 year ago

I am currently enhancing the @polkadot-api/client by integrating support for the "best block". This feature's implementation was deferred due to its complexity, particularly because the best block operations differ significantly in their trade-offs and guarantees for users. These operations are primarily suited for optimistic-updates, with the understanding that any ongoing operations on a best block that fails to achieve finalized status will result in a known, documented error, followed by the immediate unpinning of the block.

However, while implementing the best block API, I've encountered a potential ambiguity in the current specification: the best block can occasionally be unknown. This raises a question: Is this a deliberate aspect of the design, or an oversight in the specification?

Your insights on whether this is an intentional aspect of the design or an oversight would greatly aid in steering the implementation in the right direction.

cc: @tomaka

josepot commented 1 year ago

bestBlockHash is guaranteed to be equal either to the current finalized block hash, or to a block reported in an earlier newBlock event.

Actually, never mind: the case in which I considered it to be unknown is in fact when the best-block points to the currently finalized block. So, this is clearly intentional. I guess that it makes sense.

I was under the impression that the best-block was supposed to always point to a block which is not yet finalized, which is the one that's the most likely to become the next finalized block. However, I supposed that it makes sense for the best-block to point to the current finalized one while it can't be known which one it is the block that's most likely to become the next finalized block? 🤔

tomaka commented 1 year ago

It is intended, and happens actually commonly whenever a parachain stalls.