feat: storage radius check - #618
Open
akrem-chabchoub wants to merge 11 commits into
Open
Conversation
…g-storage-radius checks
…gered the increase
akrem-chabchoub
marked this pull request as ready for review
August 20, 2026 12:15
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
feat: add storage-radius check
What this tests
Every Bee node has limited storage (its "reserve"). When the reserve fills up,
Bee is supposed to shrink its storage radius (by making
radius++, meaning it becomes responsiblefor a smaller slice of the network's data, so it can evict chunks it no
longer needs to keep. When the node later has room again (e.g. because
someone stretches out their postage batches so their chunks belong elsewhere),
the radius should grow back.
This check proves that behavior actually happens on a running cluster:
outside the radius).
If either step doesn't happen, the check fails and tells you why.
How it works, step by step
warming upstatus;wait until every node is past that before testing anything.
the uploads. Reuse one if a usable batch from a previous run already
exists (saves time and on-chain fees); otherwise buy a new one.
all nodes in parallel, in waves, pausing briefly between waves so a
background watcher can check whether we've uploaded enough yet (this
avoids uploading way more than needed).
a radius greater than 0. Remember which node it was.
reserve instantly; there's a queue. Wait for that queue to drain (or skip
this if the reserve is already basically full, since backlogged chunks
will just get evicted anyway).
its stake over more of the network and pushes its chunks outside the
node's storage radius.
until its radius drops below where it was. If it doesn't drop within the
timeout, fail with the node's current chunk count and sync rate so it's
easy to tell why.
What's included
pkg/check/storageradius/storageradius.go— the check itself, registeredunder the name
storage-radius.IsWarmingUpon node status, so the check can tell warmup apart from agenuinely stuck node.
/debugstoreendpoint (previously untyped),used to read how many chunks are still queued for upload.
bee-playgroundcluster.How to run it
Requires a Bee image with a small reserve capacity (a few thousand chunks
instead of millions) — otherwise filling the reserve for real would take
far too long to ru.