Fix: Ensure Real-Time Data Retrieval in RootChain Methods (Checkpoint delays)

[JJordan0K]

Overview

This PR addresses an issue with the getLastChildBlock method in the RootChain class where the data retrieved was 17 minutes old. The change ensures that the data is retrieved in real-time.

Changes

Replaced the direct call to method.read with this.processRead in the getLastChildBlock method to ensure real-time data retrieval.

Motivation

The previous implementation was returning outdated data, which could lead to inconsistencies and incorrect information being processed. This change ensures that the most up-to-date data is used.

Differences:

1. Direct Method Call vs. Process Method:

   • The original code directly calls the read method on the method object, passing in an empty object and a default block value.
   • The updated code calls this.processRead with the method object as an argument.

2. Handling of Default Block:

   • In the original code, the default block is determined by this.client.config.rootChainDefaultBlock || 'safe'.
   • In the updated code, the handling of the default block is abstracted away within the processRead method. However, for the getLastChildBlock method, a default block is not needed because it specifically retrieves the latest block. Passing a block would result in retrieving an older block.

3. Timing of Data Retrieval:

   • The original code might be fetching data based on a specific block, which could be causing the 17-minute delay.
   • The updated code, by using processRead, might be fetching the latest data in real-time, depending on how processRead is implemented.

Conclusion:

The real difference is that processRead does not require a default block, allowing it to fetch the latest block directly. This ensures that the data retrieved is up-to-date, whereas the direct call to method.read might be fetching data from a specific block that is not current. Additionally, processRead provides additional processing and validation, ensuring that transaction options are valid and properly handled. By using processRead, we leverage existing functionality that is already used in other parts of the code, ensuring consistency and reliability. Although processRead ultimately calls method.read, it does so after performing necessary checks and configurations, making it a more robust and reliable approach.