Starknet pending blocks

Describe the bug

On Starknet, there is currently a discrepancy between the latest block and the pending block, resulting in a delay:

When we invoke the RPC get_block method, the response we receive is as follows:

{
  "jsonrpc": "2.0",
  "result": 631836,
  "id": 0
}

As evidenced on Starkscan, the latest mined block is indeed 631836, and the subsequent block will be 631837.

Notably, block 631836 has an age of 11 minutes, while the expected time between blocks is 6 minutes. This disparity suggests that the latest block returned by the RPC is not the true latest block, but rather the block preceding it.

631838 -> actual pending block 631837 -> real latest block, yet to be returned by the RPC 631836 -> latest block returned by the RPC

Although transactions achieve finality in pending blocks, this delay creates two user experience issues for Starknet users and the decentralized applications (dapps) utilizing the RPC:

Indexers:

To deliver an optimal and expedient experience, we must index pending transactions in real-time within the pending block and subsequently tag these transactions with a block number after the RPC provides us with the latest block. However, this delay causes our indexer to incorrectly tag some transactions, as there is a lag between when the sequencer furnishes our node with the block.

A potential solution on our end would be to re-parse all transactions and compare our indexed data with the contents of the newly produced block.

Events:

While the previous issue can be resolved independently, it precipitates another user experience problem. Events are genuinely emitted by the node, and if the Starknet sequencer is operating in a sluggish mode, it results in a substantial delay in event production. In our case, since we utilize a custom L3 sequencer with a messaging system that monitors events on the latest block, there is a significant lag before we can mark a swap as complete, for instance. However, this is also an impediment for other applications that rely on events to update the status for their users based on those events.

How to reproduce: You can use the following code to reproduce the issue https://github.com/ArkProjectNFTs/block-issue-sample

Expected behavior

We would anticipate the RPC to provide us with the true latest block produced, even if the sequencer has not yet finalized its operations on that block. A method to obtain the non-mined block could potentially be a solution, allowing indexers to differentiate the pending block from the one awaiting production.
How can we devise a way to receive events before they are emitted? Is it possible to emit them prematurely?

ArkProjectNFTs / ark-project

Starknet pending blocks #340