Nodes can receive a wake up violation when they are actually shutting down

Open
#29 3 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
35/100
Issue type
Bug
Clarity
Mostly clear
Activity status
Stale
Tech stack
rust
Domain
blockchain

Research direction

Trace the minting handling for uptime reports, power state changes, and power target changes, using the six-step sequence in the issue as the reproduction scenario. Compare the minting behavior with the Zos operation order mentioned in the report. Done means a node shutting down after a prior wake target does not receive a wake-up violation.

Written by the indexing model from the issue text.

Description

I've observed a rare possibility that a node can receive a wake up violation for failing to boot within 30 minutes when the node is in fact shutting down.

Here's the sequence of events:

  1. Node boots due to farmerbot. Upon boot it sends an uptime report resulting in both power_managed and power_managed_boot set to None
  2. But, in the same block as that uptime event, there is also a power target change for Up for this node. Maybe this shouldn't happen in normal circumstances, but it can and actually has. Since the power state for this node is still Down at this point, power_managed_boot will be set
  3. The node only sets its power state to Up in the next block after its first uptime report, typically
  4. There is a power target change to Down for this node more than 30 minutes after the target change to Up
  5. When the node shuts down, it first sets its power state to Down and thus both power_managed and power_managed_boot are not None
  6. Next, the node sends a final uptime report before shutting down (usually in the next block after the power state change). At this point, minting interprets this uptime report as a wake up event and assigns the node a violation

If we accept that it's legitimate to send multiple power target changes until a node wakes up, then this definitely shouldn't result in a violation.

Perhaps the solution would be to reorder the sequence of operations in Zos, but I guess that it was implemented this way for a reason, and of course rolling out changes to Zos is slow.

Dominant language
Rust
Stars
0
Forks
0
No merged PRs in 30d

Contributor guide

No contributing guide indexed for this repository

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from threefoldtech/ledger_minting

All issues in threefoldtech/ledger_minting

Similar issues

More Rust issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.