Desync between redistribution game phase tracked by node and on-chain (need to investigate)
Maintainers usually reply within 2 days
@sbackend123 is already working on this.
Since Jun 1, 2026.
Assessment
This issue has not been assessed yet.
Description
Context
An on-chain round is split into commit → reveal → claim. When round N enters claim, the agent publishes the internal sample phase and runs handleSample. At the start of handleSample, IsPlaying() is called — an eth_call to the contract’s isParticipatingInUpcomingRound(owner, committedDepth) — to check whether the node will fall in the neighbourhood for the next round (N+1). Building the sample can take a long time and may overlap with commit of round N+1; IsPlaying is not called again during that work (only once at the beginning of sample).
Problem
The bee_storageincentives_is_playing_errors metric keeps increasing steadily.
Logs on light testnet show phase failed, phase=sample, with errors like
IsPlaying: ... execution reverted: 0xe2586bcc. As I understand, selector decodes to WrongPhase().
In the contract, isParticipatingInUpcomingRound reverts with WrongPhase() only when the call lands in the on-chain reveal phase (currentPhaseReveal()). It should not revert for phase reasons during claim or commit.
If IsPlaying fails, no sample is created → the node does not participate in that game round.
Hypothesis
I suspect a desync between the phase the node believes it is in and the actual on-chain phase. Because of these frequent errors, the node rarely passes the gate before sampling and participates in the game only rarely
- Dominant language
- Go
- Stars
- 1.5k
- Forks
- 390
- Avg merge
- 2d 11h
- Merged PRs (30d)
- 23
Getting set up
- Ships a Dockerfile or Docker Compose file
- Has a pull request template
- Read the contributing guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from 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)Possibly taken @sbackend123 claimed this 9 days ago. Open
Difficulty 2/5 1-3 hours Newbie friendliness 85/100
ethersphere/bee#5650 · 1 assignee ·
Maintainers usually reply within 2 days
-
Add a transaction inbox for outbound chain transactionsPossibly taken @sbackend123 claimed this 3 days ago. Openseen
Difficulty 5/5 Over a week Newbie friendliness 35/100
ethersphere/bee#5660 · 1 assignee ·
Maintainers usually reply within 2 days
-
Difficulty 4/5 3-5 days Newbie friendliness 45/100
ethersphere/bee#5659 ·
Maintainers usually reply within 2 days
-
accepted seen
Difficulty 4/5 3-5 days Newbie friendliness 40/100
ethersphere/bee#5648 · 1 comment ·
Maintainers usually reply within 2 days
-
pusher: chunksWorker deadlocks on a deferred chunk that fails IdentityAddress (send on nil op.Err), halting all push-syncPossibly taken @sbackend123 claimed this 11 days ago. Openseen
Difficulty 3/5 1-2 days Newbie friendliness 75/100
ethersphere/bee#5641 · 1 assignee ·
Maintainers usually reply within 2 days
Similar issues
-
triage
Difficulty 2/5 1-3 hours Newbie friendliness 86/100
wakatime/wakatime-cli#1649 ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
danielgtaylor/huma#1135 ·
Maintainers usually reply within 1 day
-
needs-triage
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
stacklok/toolhive-catalog#1734 ·
Maintainers usually reply within 1 day
-
documentation priority:p1
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
yeixio/toskar-core#697 ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
keyxmakerx/Chronicle#1532 ·
Maintainers usually reply within 1 day