-
Notifications
You must be signed in to change notification settings - Fork 359
fix(miner): Do not use pending block for now #1255
Conversation
WalkthroughThe changes primarily focus on modifying the retrieval of blocks and their states in the Ethereum backend. The logic now uses the current block header from the blockchain instead of the miner's pending block, ensuring more accurate and up-to-date data retrieval. Changes
TipsChat with CodeRabbit Bot (
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Review Status
Actionable comments generated: 0
Configuration used: CodeRabbit UI
Files selected for processing (1)
- eth/polar/api_backend.go (2 hunks)
Additional comments: 4
eth/polar/api_backend.go (4)
246-247: The new code fetches the current block from the blockchain instead of the miner's pending block when the block number corresponds to the pending block. This change seems to be aimed at avoiding potential inconsistencies or errors that might arise from using a pending block. However, it's important to ensure that this change doesn't break any functionality that relies on the pending block in this context.
312-320: Similar to the previous hunk, the new code fetches the current block header from the blockchain instead of the miner's pending state and header when the block number corresponds to the pending block. Again, verify that this change doesn't break any functionality that relies on the pending state and header in this context.
324-327: The error handling here is good, as it ensures that any error encountered while resolving the block number and retrieving the header is properly returned. This allows the caller to handle the error appropriately.
329-331: The check for a nil header and the corresponding error return is a good practice. It ensures that the function doesn't proceed with a nil header, which could lead to a runtime panic. The use of a predefined error (
core.ErrBlockNotFound
) also helps with consistency and potential error handling by the caller.
Signed-off-by: Devon Bear <[email protected]>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Review Status
Actionable comments generated: 0
Configuration used: CodeRabbit UI
Files selected for processing (1)
- eth/polar/api_backend.go (2 hunks)
Additional comments: 2
eth/polar/api_backend.go (2)
- 246-247: The new code retrieves the current block from the blockchain instead of the pending block from the miner. This change could potentially affect the behavior of any code that relies on the pending block. Ensure that this change does not introduce any unintended side effects.
- block := b.polar.miner.PendingBlock() - return block, nil + header := b.polar.blockchain.CurrentBlock() + return b.polar.blockchain.GetBlock(header.Hash(), header.Number.Uint64()), nil
- 312-319: Similar to the previous comment, the new code retrieves the current block from the blockchain instead of the pending state from the miner. This change could potentially affect the behavior of any code that relies on the pending state. Ensure that this change does not introduce any unintended side effects.
- block, state := b.polar.miner.Pending() - return state, block.Header(), nil + header = b.polar.blockchain.CurrentBlock()
This reverts commit 9c25a75.
This reverts commit 9c25a75.
Summary by CodeRabbit