Skip to content

Conversation

@Nathy-bajo
Copy link
Contributor

No description provided.

@Nathy-bajo Nathy-bajo requested a review from tom-blk October 22, 2025 15:25
Copy link
Collaborator

@tom-blk tom-blk left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The way that this works now looks better, but I don't understand why update_operational_status is not in tx_builder and the check_for_acceptable_operational_status_error is essentially the same as the original check_for_acceptable_error function? Is there a specific reason for this?

@Nathy-bajo Nathy-bajo requested a review from tom-blk October 27, 2025 14:35
Copy link
Collaborator

@tom-blk tom-blk left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good overall, but if I am understanding this correctly, the miner now gets it operational state from itself and stores in the Miner struct. That still causes an issue, because the point is for the miner to react to the chainstate so it should

  • start up
  • check chainstate
  • update own state based on chainstate

Also is there a reason why we need the last_operational_status in the miner at all? Why is it not enough to keep track if the miner has a task with current_task or not?

@Nathy-bajo Nathy-bajo requested a review from tom-blk November 3, 2025 08:49
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants