Bee node stuck unhealthy due to storage radius mismatch (10 vs neighborhood 9), redistribution never resumes
I maintainer di solito rispondono entro 2 giorni
Nessuno ha ancora preso questa issue.
- #5463 di @martinconic — chiusa senza merge
Valutazione
- Difficoltà
- 5/5
- Tempo stimato
- Più di una settimana
- Idoneità per principianti
- 25/100
- Tipo di issue
- Bug
- Chiarezza
- Abbastanza chiara
- Stato di attività
- Ferma
- Stack tecnologico
- go
- Ambito
- backend, distributed-systems
Direzione di ricerca
Start by tracing the storage-radius discrepancy check and radius-convergence logic, then inspect how reserve state and redistribution health are recalculated after sync recovery. The issue names no source files or tests, so first locate those entry points in the Go codebase. Done means the node can recover from the reported radius mismatch and resume redistribution; validate with focused tests for the recovery path.
Scritto dal modello di indicizzazione a partire dal testo della issue.
Descrizione
Context
- Bee version: 2.7.1-rc2
- Running in Docker
- Full node (full-node: true)
- Mainnet enabled
- Swap + storage incentives enabled
- Stable RPC backend (HAProxy in front of multiple Gnosis RPC providers)
- Node has been running continuously for several days
Summary
Node enters a persistent state where:
- isFullySynced = true
- hasSufficientFunds = true
- isFrozen = false
but:
- isHealthy = false
- node does not participate in redistribution (lastPlayedRound remains unchanged)
Logs indicate a storage radius discrepancy:
node is unhealthy due to storage radius discrepancy
self_radius=10 network_radius=9
The condition persists indefinitely and does not self-correct over time.
Expected behavior
Once the node is:
- fully synced
- well connected
- sufficiently funded
- not frozen
…it should eventually:
- align its storage radius with the neighborhood
- transition to isHealthy = true
- resume participation in redistribution rounds
Actual behavior
The node remains stuck in the following state:
- isFullySynced = true
- hasSufficientFunds = true
- isFrozen = false
- isHealthy = false
Redistribution does not resume:
{
"lastPlayedRound": 283212,
"round": 2995xx
}
State remains unchanged for multiple days.
Steps to reproduce
Not fully deterministic, but observed sequence:
- Node operates normally and participates in redistribution
- Node experiences RPC instability (temporary backend connectivity issues)
- After RPC is stabilized, node resumes syncing and connectivity
- Node reaches:
- isFullySynced = true
- healthy peer count (~120+)
- Node enters persistent state:
- storageRadius = 10
- neighborhood peers predominantly at storageRadius = 9
- isHealthy = false
- redistribution no longer progresses
Restarting the node:
- temporarily sets isHealthy = true while isFullySynced = false
- once fully synced, state reverts to unhealthy
Possible solution
Unknown.
From observation, node does not automatically converge its storageRadius to match neighborhood consensus once mismatch occurs.
Possible areas to investigate:
- radius convergence logic after sync recovery
- reserve state recalculation after RPC disruption
- conditions under which storageRadius is allowed to decrease
Additional diagnostics
/status
{
"storageRadius": 10,
"connectedPeers": 135,
"isReachable": true
}
/reservestate
{
"radius": 11,
"storageRadius": 10
}
/redistributionstate
{
"isHealthy": false,
"isFullySynced": true,
"lastPlayedRound": 283212
}
Peer observation
Nearby peers (via /status/peers) are predominantly:
storageRadius: 9
AI Disclosure
- This issue contains suggestions and text generated by an LLM.
- I have reviewed the AI generated content thoroughly.
- I possess the technical expertise to responsibly review the AI generated content mentioned in this issue.
- Lingua principale
- Go
- Stelle
- 1.5k
- Fork
- 390
- Merge medio
- 3g 58m
- PR unite (30g)
- 25
Preparare l'ambiente
- Include un Dockerfile o un file Docker Compose
- Ha un modello di pull request
- Leggi la guida per i contributori
Come iniziare
- Leggi tutta la issue e poi la guida ai contributi del progetto.
- Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
- Fai un fork del repository e lavora su un branch.
- Apri una pull request che faccia riferimento al numero della issue.
Altre issue di ethersphere/bee
-
Chequebook deployment uses a fixed 175,000 gas limit; it needs about 630,000 under Glamsterdam (live on Sepolia since 2026-10-06)Forse già presa @sbackend123 l’ha presa 19 giorni fa. Aperta
Difficoltà 2/5 1-3 ore Idoneità per principianti 85/100
ethersphere/bee#5650 · 1 assegnatario ·
I maintainer di solito rispondono entro 2 giorni
-
Difficoltà 4/5 3-5 giorni Idoneità per principianti 35/100
ethersphere/bee#5678 ·
I maintainer di solito rispondono entro 2 giorni
-
Difficoltà 4/5 3-5 giorni Idoneità per principianti 48/100
ethersphere/bee#5666 ·
I maintainer di solito rispondono entro 2 giorni
-
Add a transaction inbox for outbound chain transactionsForse già presa @sbackend123 l’ha presa 13 giorni fa. Apertaseen
Difficoltà 5/5 Più di una settimana Idoneità per principianti 35/100
ethersphere/bee#5660 · 1 assegnatario ·
I maintainer di solito rispondono entro 2 giorni
-
Difficoltà 4/5 3-5 giorni Idoneità per principianti 45/100
ethersphere/bee#5659 · 6 commenti ·
I maintainer di solito rispondono entro 2 giorni
Tutte le issue di ethersphere/bee
Issue simili
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 78/100
containerd/containerd#14476 · 1 commento ·
I maintainer di solito rispondono entro 1 giorno
-
kind/bug
Difficoltà 2/5 1-3 ore Idoneità per principianti 78/100
ome-projects/ome#1242 ·
I maintainer di solito rispondono entro 1 giorno
-
copy design-review mac P3
Difficoltà 2/5 1-3 ore Idoneità per principianti 88/100
tosunlab/hisarapp-core#510 ·