Fix chain_get_block_transfers RPC so that it returns an empty array of transfers instead of null if the block didn’t have any transfers. #4255
Assignees
Comments
Merged
casperlabs-bors-ng bot
added a commit
that referenced
this issue
Sep 6, 2023
4272: Fix issues in storage r=Fraser999 a=Fraser999 This PR fixes two separate issues: * a historical synced block with no deploys would have no entry written for it in the `transfers_db`, causing the JSON-RPC `chain_get_block_transfers` to report the block's transfers as `null` rather than `[]` * for a block with a non-zero number of successful transfers, if its execution results were put to storage more than once, the initial valid entry in the `transfers_db` would be overwritten with an invalid empty collection, causing the JSON-RPC `chain_get_block_transfers` to report the block's transfers as `[]` rather then the correct value Th fix is to have `Storage` reconstitute the correct value when reading from `transfers_db` if it encounters a missing value or an empty collection, and store the corrected value before returning it. The `Storage::write_execution_results` method has also been corrected to not overwrite good values with empty collections. Closes #4255. Closes #4268. Co-authored-by: Fraser Hutchison <fraser@casperlabs.io>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Issue was reported here. When a joiner node is synchronizing historical blocks, if the block doesn’t have any deploys, we don’t write an empty record in the transfers DB. When trying to get the transfers for such block through the chain_get_block_transfers RPC, it will return null since no such record was written while syncing. We need to adjust the RPC (or the storage method for getting transfers) to return an empty array in this case. We also shouldn’t be storing empty records preferably if there are no successful transfers in that block.
The text was updated successfully, but these errors were encountered: