Key Changes

Start node from snapshot without blocks

Issue:
In Leap v4.0.1, an issue was identified where attempting to start a node from a snapshot that had no blocks in the blocks folder resulted in an error. Despite trying different snapshots and various configurations, the error persisted.

Impact:
The inability to start a node from a snapshot without blocks required manual workarounds to ensure the node could start properly and could prevent some node operators from upgrading to Leap v4.x.x.

Resolution:
The issue has been resolved in Leap v4.0.2 with the following fixes:

1. Added a test for reading a snapshot with no block log option.
2. Improved assertion message for better diagnostics.
3. Fixed the empty block log to support loading from a snapshot.
4. Implemented additional tests for empty block log scenarios.
5. Handled the loading of a snapshot without a block log but with an existing fork database.
6. Ensured correct handling of forks during snapshot loading.

Intermittent Missing Blocks in State History Reader

Issue:
In Leap v4.0.1, a state history reader was tested with a fork case and encountered a problem where it would get backed up and miss blocks after a certain point. Analysis revealed a null value for "this_block" in the ship plugin log, indicating an issue with block retrieval.

Impact:
The intermittent missing blocks had the following implications:

1. Incomplete state history data.
2. Disruption in data analysis and processing.
3. Potential inconsistencies in system behavior.

Resolution:
To address this issue, the following actions were taken in leap v4.0.2:

1. Fixed the intermittent empty get_block_result
2. Merged the fix into main

Prevent rapid increase in syslog size caused by excessive info logs

Summary:
In Leap (v4.0.1), Nodeos was observed to generate an excessive number of info logs, resulting in a substantial increase in the size of the syslog.

Impact:
The syslog size could grow up to 5GB within an hour, significantly affecting system performance and disk space utilization. The excessive info logs generated by nodeos had the following potential impacts on the system:

1. Potential infinite loop in the net_plugin.
2. Consumption of disk space.
3. Degraded system performance.
4. Increased log noise.

Resolution:
To address this issue, the following actions have been taken in leap v4.0.2:

1. Resolved an infinite loop in the net_plugin by preventing the sending back of a handshake message under specific conditions
2. Improved the close process handling when not in sync to mitigate excessive logging
3. Implemented enhanced timestamp handling and round-trip time calculations to reduce log entries and avoid message spamming

Fix startup segfault after clean shutdown

Issue:
In the previous version of Nodeos (v4.0.1), an issue was identified where the application would segfault during startup after being cleanly stopped for backup.

Impact:
Symptoms of the issue included the generation of multiple info logs related to net_api_plugin and http_plugin.

Resolution:

1. Code change in v4.0.2: allow ROtrx threads unlimited time to start.
2. Suggested workaround: set read-only-threads = 0 if chain_api_plugin is enabled on a non-public api node.

state-history-log-retain-blocks option handling

Issue:
In Nodeos version 4.0.1, an error occurs during the plugin initialization of the state_history_plugin: "Plugin exception: state history log prune configuration requires at least one block."

Impact:
The startup error hinders the proper initialization of the state_history_plugin.

Resolution:
The issue was identified as a bug in handling the state-history-log-retain-blocks option. To resolve this issue, the following actions were taken in leap v4.0.2 through pull requests:

1. Fix state-history-log-retain-blocks option handling
2. Merge changes into the main branch

Fix parsing Error in get_transaction_id Endpoint for CURL Requests

Issue:
In the previous version of leap (v4.0.1), an issue was identified in the get_transaction_id endpoint when making CURL requests. Specifically, when sending a transaction JSON similar to the one accepted by cleos, a parsing error occurred.

Impact:
The parsing error resulted in the following impacts:

1. Failed CURL requests with a parsing error message: "Unable to parse valid input from POST body."
2. Inability to retrieve valid transaction IDs through CURL requests, leading to disruptions in transaction processing and related operations.

Resolution:
To resolve this issue, the following actions were taken in leap v4.0.2:

1. Accept both data and hex-data, aligning with the behavior of cleos.

Please note that these improvements are included in the Leap 4.0.2 release, providing users with a reliable and consistent experience when utilizing CURL requests for transaction processing.

Occurrences of "peer sent a handshake with a timestamp skewed by at least -2ms" persist

Issue:
Despite applying the patch for issue #1240 on top of Leap 4.0.1, the occurrence of log messages indicating timestamp skew persisted.

Impact:
The continuous log messages caused confusion and added noise to the system logs. The actual clocks were not skewed, as evidenced by similar block arrival times reported by nodes. However, the misleading log messages raised concerns and created unnecessary alarm.

Resolution:
To address this issue, the following actions were taken in Leap 4.0.2:

1. Refactored the logging behavior to reduce warning messages for insignificant clock skew that does not impact system operations.

Further details

Contributors

Special thanks to the contributors that submitted patches for this release:

• @iamveritas
• @spoonincode
• @heifner
• @766C6164
• @heifner
• @Lin2931

Full list of changes since last release

Full Changelog: v4.0.1...v4.0.2